Weird access behavior to a library

[W1ndwaker]

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

[Kurt_Bremser]

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).

[SimonMcGrother]

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

[W1ndwaker]

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)

[W1ndwaker]

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

[Kurt_Bremser]

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.

[Tom]

---

@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.

[Kurt_Bremser]

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.

[Tom]

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?

[W1ndwaker]

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.

[Kurt_Bremser]

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?

[W1ndwaker]

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.

[Kurt_Bremser]

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?

[Tom]

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.

[Sajid01]

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.