BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
Dph
Calcite | Level 5 Dph
Calcite | Level 5

We have a team of EG users with some users have read only and some have write access for a certain library. I noticed that users can rename a dataset even if they have only read access to a library. Below are the settings:

 

Folder permission:

drwxrwx--- 2 sas_admin sas 7 Sep 6 16:12 testlib1

 

Dataset permission:

-rw-rw---- 1 sas_admin sas 196608 Sep 6 15:32 cars.sas7bdat

 

We registered the table in SMC and set the permission of user for both library and registered table:

Dph_0-1630916733862.png

 

They cannot delete or update the dataset but they can still rename it. 

 

Any thoughts how can we prevent this?

 

1 ACCEPTED SOLUTION

Accepted Solutions
Kurt_Bremser
Super User

As long as users have write permission for the directory on the operating system level, you will not be safe.

Remove the group write permission, and give only privileged users write permission via access control lists. This is what I have done for decades.

View solution in original post

9 REPLIES 9
LinusH
Tourmaline | Level 20

Data authorization can be a bit complicated.

If you don't enforce the use of META engine, permission set in SMC has "no" effect - only Linus/UNIX folder permissions are in effect.

Data never sleeps
Dph
Calcite | Level 5 Dph
Calcite | Level 5
Hi,
Yeah, sorry I did not mention but the libraries are assigned using meta engine:

LIBNAME TESTLIB1 META LIBRARY='TESTLIB1' METAOUT=DATA;
Patrick
Opal | Level 21

Yes and no. "METAOUT=DATA" will also show tables not registered in SAS Metadata.

 

The only way to really secure your data is on OS level as users will always have the option to issue a different libname via code and then only OS level permissions apply.

 

If you really want to ensure that data access is only possible via the libnames defined in SAS Metadata then you need a metadata bound library.

Dph
Calcite | Level 5 Dph
Calcite | Level 5
Yes I know the metaout=data will show all the tables but the dataset in question is a registered one.. I also understand the risk you mentioned.

I have to read about it since I am not familiar with metadata bound libraries, but may I know if we implement this will it prevent the 'read only' users from renaming of the datasets?
Kurt_Bremser
Super User

As long as users have write permission for the directory on the operating system level, you will not be safe.

Remove the group write permission, and give only privileged users write permission via access control lists. This is what I have done for decades.

Dph
Calcite | Level 5 Dph
Calcite | Level 5

I see, so it really cannot be controlled in metadata level. I haven't done any ACLs before but I just tested sample files/folders and it seems to work as expected. It will be a bit tedious because we have around 50 libraries and 30 users in that team, although only 20% of them have write access in each of the library.

 

Thanks, everyone.

Kurt_Bremser
Super User

With "not be safe" I meant that there might always be a way for users to copy and remove (resulting in a rename) files with the FCOPY and FDELETE functions.

The FCOPY and FDELETE functions do not care about library metadata when you use them with .sas7bdat files (a dataset is then just a file like any other file).

Even easier is the use of the mv system command if you have XCMD enabled or the users have access to the commandline with SSH.

The only thing that can prevent these actions is the operating system.

Kurt_Bremser
Super User

You could control it exclusively in metadata if you used SAS Token Authentication and a pooled workspace server, which would mean that for the OS only the sassrv user would read and write datasets, and you could set all libraries to drwx------ with owner sassrv. But that is not what you usually do, as you lose control over what an individual user does (disk storage, CPU consumption, etc).

Dph
Calcite | Level 5 Dph
Calcite | Level 5

Pooled workspace server setup will not be feasible, primarily because of the regular audit / security review.. Most likely will have to do combination of dataset registration + ACLs. Though I have to test further. 

 

Thank you for your inputs

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 9 replies
  • 1318 views
  • 0 likes
  • 4 in conversation