topic Re: Weird access behavior to a library in Administration and Deployment

Weird access behavior to a library

W1ndwaker — Wed, 07 Aug 2024 08:52:45 GMT

Hello all,

i'm facing a weird situation with sas setup, we have a sas 9.4m7 installed on RHEL, everything seems to be working fine.

We use the system level folders to map some libraries to the end users, we have a set of permisions on the folder which are a ldap group assigned to the folder, and the owner is sas, normally this works fine and if you're not in the users group you cannot map the library.

The point is that we've created a new workspace server with a set of libraries (os folder) assigned to it with it's specific group, and the weird thing comes when someone tested the access to the library and got it correctly, but the group has no users assigned to it.

Then i've made some tests with this folder, for example I have 2 users that can map the folder in their eguid, 1 is a sas administrator and the other a regular end user, but none of them are in the ldap group that grants access to the folder, and I have no access to the library nor the group.

The first test i did to check the situation was to access to the server with the user directly and try to create a test file and that didn't work (as expected since the user is not in the group) but then it makes me think what is happening in eguide that lets this users to map the folder and create datasets, the only thing that comes to my mind is that eguide creates a sesion with user sas (and then impersonate as the end user) and this is why it lets the user map the library.

I've also tryied some other test like checking the users and comparing the permissions in the management console, and everything seems fine, all users are the same and have the same config as me, except 1 of them that has admin role. Also I put myself in the gruop to see if i had access to the folder and that worked fine, so it's how is supossed to be.

Does anyone have a clue of what can be happening? since we can have a posible security breach here if a user can map libraries that's not supossed to have access.

thanks

Re: Weird access behavior to a library

Kurt_Bremser — Wed, 07 Aug 2024 12:31:42 GMT

If you want to control access through metadata, you must make those libraries metadata-bound. Otherwise, you have to use the operating system (which means access control lists if you have more than one group per library).

Re: Weird access behavior to a library

SimonMcGrother — Wed, 07 Aug 2024 12:43:27 GMT

Not an expert by any means, but this documentation might help: https://documentation.sas.com/?cdcId=bicdc&cdcVersion=9.4&docsetId=bisecag&docsetTarget=n1nesjvtxu7783n1pveml8ct4txk.htm

Re: Weird access behavior to a library

W1ndwaker — Wed, 07 Aug 2024 12:43:36 GMT

It's only one group per folder, it's a very easy set up.

The thing is that if you're not in the group you should'nt be able to access, but the thing is that the users can map the library in eguide, but cannot do a cd <<directory>> in the server

Re: Weird access behavior to a library

W1ndwaker — Wed, 07 Aug 2024 12:48:20 GMT

it's a possiblity, but we're migrating to another security solution, but in the meantime i wanted to know what is happening with this situation, without using the metadata.
(note: we had this security level system for this kind of enduser libraries for a long time and never seen this behavior)

Re: Weird access behavior to a library

Tom — Wed, 07 Aug 2024 13:08:10 GMT

So your SAS sessions are running on Linux?

What are the permissions on the directory?

770 would give the owner (user that owns the directory) full rights and the group (group that owns the directory) full rights and others would not even be able to read the contents of the directory.

You mentioned LDAP. How are you mapping LDAP permissions to Unix permissions?

You talk about mapping the library. But that is just setting up the pointer to where to look for the files. Did you also test whether they can actually read any of the datasets in that library? Do you expect the users to be able to modify the datasets in that library? Did you test if they could make a new dataset in that library?

Re: Weird access behavior to a library

Kurt_Bremser — Wed, 07 Aug 2024 13:12:41 GMT

The permission for the directory should be rwxrwx--- (or rwxr-x--- if only the owner may write datasets to it). If you have rwxrwxr-- the users can't cd into the directory, but read the directory file, which is sufficient for EG.

Re: Weird access behavior to a library

Tom — Wed, 07 Aug 2024 13:27:02 GMT

@Kurt_Bremser wrote:

The permission for the directory should be rwxrwx--- (or rwxr-x--- if only the owner may write datasets to it). If you have rwxrwxr-- the users can't cd into the directory, but read the directory file, which is sufficient for EG.

Just to clarify the difference between r-x and r-- is that without the execute permission directory access does not really work. You might be able to read the directory as a binary file, but you cannot see the list of file that are inside it (unless you parse the contents yourself), and you definitely cannot access any of the files in the directory.

Re: Weird access behavior to a library

Kurt_Bremser — Wed, 07 Aug 2024 15:48:53 GMT

ls will work with only the read permission (as you only read the contents of the directory). ls -l won't work, as for this you need to access the individual inode of each file, and for this the x permission is needed.

So, if EG only reads names, the r on its own will work, but any further access (e.g. SETting a dataset) will fail.

Re: Weird access behavior to a library

W1ndwaker — Thu, 08 Aug 2024 06:26:30 GMT

770 is what i set to the directory, the thing is that you can map your login or security of the groups on a linux machine to a ldap trough a bind, with that set i have onwer sas and for the group there is an ldap group empty.

the question is why if the group is EMPTY some users can map the library without getting the error for user access insuficent rights?

my point is that i think that something goes on behind the session open on the server that lets some users access to directories that shouldn't have, and i would like to know what it is.

Note: applying meta bound libraries would solve the problem for sure, but at the moment we cannot apply this change since we're in the middle of another project.

Re: Weird access behavior to a library

Kurt_Bremser — Fri, 09 Aug 2024 11:56:17 GMT

Please check if users able to „map“ the directory can also work with it (read datasets from there, or create them).
What do you mean by EMPTY? Are you saying that the directory has a group ownership for a group not contained in your LDAP source?
Did you check if there are access control lists defined for the directory?

Re: Weird access behavior to a library

Sajid01 — Sat, 10 Aug 2024 23:20:43 GMT

Hello @W1ndwaker
I hope you have defined a new APP Server Context (for example SAS APP2) for the new workspace server.
Make sure that the library is defined in the Workspace Server Autoexec_usermod and not at the App Server level.

Re: Weird access behavior to a library

Tom — Sun, 11 Aug 2024 16:48:17 GMT

You mentioned using Enterprise Guide. Can you confirm that the users are actually signing on the SAS application server using their own account and not some other account that does have the right group access?

You should be able to check the SAS automatic macro variable SYSUSERID to see the userid of the user that is running SAS.

Re: Weird access behavior to a library

W1ndwaker — Mon, 09 Sep 2024 07:02:24 GMT

Yes, i've checked that, the group is set in the directory with the chgrp, and the group is from the ldap, there are no acls or weird things, just a grup with a set of users and owner (sas admin user).

the user is able to do a libname XXX "/path";

and its able to work with datasets and create/delete them.

Re: Weird access behavior to a library

Kurt_Bremser — Mon, 09 Sep 2024 08:39:53 GMT

Log on to the server as root (or have the admin do it) and look at the process list when said user starts a new SAS session to see the owner of that process.

Is it possible you have a pooled workspace server defined?

Re: Weird access behavior to a library

W1ndwaker — Mon, 09 Sep 2024 10:40:19 GMT

Hi,

yes that is what i did, i created a new app server, then created the folder structure with permissions, and then i made a new autoexec specific to map the libraries for the server on the startup, the thing is that there are users that are not in the group of the folder that can map it and work on it.

Re: Weird access behavior to a library

Sajid01 — Mon, 09 Sep 2024 19:47:01 GMT

Hello @W1ndwaker
When you say this "the thing is that there are users that are not in the group of the folder that can map it and work on it.", it's time that these users be added to the appropriate groups both at the LDAP, SASMC and the OS level if they need access.
Typically, SAS Administrators handle these scenarios with ease. If there is something weird OR complicated, it's time that a support ticket is created with SAS Tech Support for assistance.

Re: Weird access behavior to a library

JuanS_OCS — Mon, 09 Sep 2024 19:55:47 GMT

While all of this information is true, I am with Kurt: I think you need to understand the process owner and the permissions set up, on top of your LDAP vs local groups configuration.

This is an OS question more than SAS.

Permissions in UNIX based systems are tricky and meant to be more restrictive than permissive.

If you are interested in being more in control of your Linux permissions I would suggest to apply a granular configuration with ACLs, then you gen something similar to Windows.

Re: Weird access behavior to a library

W1ndwaker — Wed, 11 Sep 2024 07:03:03 GMT

Probably your answer to apply another kind of security is the best solution, and we're underway to do it, the point is that i found this situation in the meantime we change our system and datawarehouse, and wanted to share the situation, i know it's strange and seems to be something not correctly configured on LDAP/system or a maybe it's a bug on SAS, i'll be checking it and see if i find anything, but this will be corrected applying a new security model.