I have to set up some users and libraries on a SAS system.
Let's say I have library LIB and user A and B
I want that A has read permissions to LIB
I want that B has read and write permissions to LIB
I set up those permissions explicitly on the Managemente Console user A has only Read Metadata allowed and all the rest denied
user B has all permissions.
The result is that when I log on Enterprise Guide as user A, I can modify existing tables in LIB, create new ones, delete existing ones, even if the these permissions are denied.
How is this possible?
How can I implement this idea?
From a Unix perspective, you handle this by defining groups. (You may not have the authority to set up and maintain a group, so you may need to get help on this.) Add one user to the group, but not the other.
That's what the middle set of permissions controls ... group access. Or in shorter terms, 774 = all for LIB owner, all for group, read only for the rest of the world.
After logging on, a user might have to switch from his default group over to your group to gain access.
I thought of that but It's not feasible because there are many more users and many more libraries? Isn't possible to set this up on the management console? What's the point of the Management Console with all the fine grained permissions if they don't work?
permissions / metadata security works well, lets see if we can figure out the problem.
What version of SAS are you using, and what's the EG version?
Are you familiar with this info:
Use and Enforcement of Permissions:
Permissions by Object
Permissions by Tasks
... and don't forget that table objects in metadata inherit permissions from the metadata folder in which they are contained and not the metadata library in which they are registered. For consistency you can assign permissions to a metadata folder containing both the library and the tables. Also keep in mind metadata security recommended practices and assign permissions, ideally via ACTs, on the folder, for groups (not users), only denying permissions broadly (to PUBLIC or SASUSERS) and then granting back to appropriate groups.
You will also want to consider how the library is being assigned: which engine: native or Metadata Libname Engine (MLE), and where necessary the MLE metaout value, and the AssignMode extended attribute value.
I think I followed the best practices. I set up the folder structures like this
I set up 3 ACT: ACT_A has all the permissions for user A, and read only permission for user B, ACT_B the opposite and i set up a "Deny_SASuser" to deny permission on SASUSER
On Folder_GroupA (which will cointain tabs that userA should be able to write and read and userB read only) i assign ACT_A and Deny_SASUSER.
On Folder_GroupB ACT_B and Deny_SASUSER
I then create a library in Folder_GroupA (native library, preassigned). I check the permissions on the new library. User permissions are all inherited as I wanted (all the appropried "greens" and "greys"). UserA has all the permissions, UserB has only read metadata and read.
I then log as UserA on EG (7.1 by the way) and I can create all the tabs that I want. Problem is that, when I log as UserB I can do the same.
I'd like, if possible, more clarification on native/ML engine. I tried to set Metadata Libname Engine but then I couldn't manage to create any tables with any user.
What you have done sounds about right for ensuring appropriate metadata permissions but you will also need to consider file system permissions too, being aware of the difference between creating physical tables (SAS datasets) in the physical directory in the file system and (optionally) registering those tables in metadata folders. You can create physical tables without registering the tables in metadata (and vice-versa). You might also want to submit a "libname _all_ list;" in EG to see how all of the libraries have been assigned and what engines are being used.
You wont be able to create tables in a MLE library uless you use one of the metaout options that supports it.
As you have found, this is quite a complex area with all of the various considerations. I would suggest one of the best ways to get a handle on this is to attend the SAS Platform Administration Fast Track course which covers many of these concepts.
As has been suggested by others, the 2 main options that admins use to control access to metadata and physical layers is to align metadata and file system access controls or use metadata bound libraries (to enforce the use of the metadata authorization layer).
You need to make your libraries metadata-bound, so they can only be used with the metadara engine.
Or you invest the necessary time to design a proper group structure in the OS. And solve the extreme cases with access control lists.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.
Find more tutorials on the SAS Users YouTube channel.