SAS 9.2 – Page 13 – platformadmin.com

Metacoda Security Plug-ins Tip: Where’s that login?

This is a tip for Metacoda Security Plug-ins users who might have a need to track down which user or group identity in their SAS® metadata owns a particular user id.

Have you ever gone to add a login to a user or group identity in the SAS Management Console, perhaps some database credentials for a group to share, but couldn’t because the userid had already been used elsewhere? If so then you’ll be familiar with this error:

So now you know the userid has already been used elsewhere, but where exactly? Maybe it shouldn’t have been used on the other identity, or maybe you just want to check out the other identity because you might be able to take advantage of it instead of adding a new one?

It’s easy to find that user id, and the user or group identity it is associated with, by using the Metacoda Security Plug-ins Login Reviewer, especially if you have the new 2.0 version (which works with SAS 9.3 and SAS 9.2).

To track down the login open the Login Reviewer:

… and then, in the new filter bar, type in the user id which was already used, scott in this example. You’ll then see which identity has that login. In this example the scott login is already being used on the Vegas Enterprises: Oracle Users group which is why it couldn’t be added to the Custom Oracle Users group earlier.

If you have SAS 9.1.3 SP4 and Metacoda Security Plug-ins V1.0 then you won’t have the filter bar, but you can still find the login by clicking on the userid column header to sort by user id and then scroll down to find the problem login.

So finding a login isn’t that hard after all…

SAS Deployment Manager 9.3

I noticed the user interface for the SAS® Deployment Manager 9.3 has changed slightly.

Here is a screenshot from my “old” SAS 9.2 M3 installation:

… and here’s the screenshot from my new SAS 9.3 installation:

I’m guessing that the new hierarchical folder structure is going to allow for more tools to added.

Interestingly there’s a new Apply Hot Fixes item at the bottom of the list of tools. This new tool is also mentioned in the SAS 9.3 hotfixes area under Important Changes to Hot Fixes. Initially I wondered if this was going to replace the SAS92HFADD tool, but then I saw there’s a SAS 9.3 Hot Fix Analysis, Download and Deployment Tool (SAS93HFADD) that’s currently marked as Under Development. I really liked SAS92HFADD (I did a couple of posts about my experiences with it here and here), so I’ll be interested to see SAS93HFADD when it’s available.

The documentation for the updated SAS Deployment Manager is in the SAS Deployment Wizard and SAS Deployment Manager 9.3: User’s Guide which is available from a link at the bottom of the SAS 9.3 Install Center Documentation page. This is one of those documents that I don’t refer to often enough to always remember where to find it. I hope it makes it onto the very useful, all-in-one page SAS 9.3 Documentation by Title.

WriteMemberMetadata Permission

The WriteMemberMetadata (WMM) permission was a welcome addition back when SAS 9.2 was released, because it allowed an administrator to distinguish between a users ability to manage a metadata folder from their ability to manage its contents.

In SAS 9.1.3 there was only the WriteMetadata (WM) permission and, if you had the ability to manage a folders contents, then you also had the ability to manage the folder too (and that could mean being able to change its permissions as well).

Starting with SAS 9.2, if someone had an effective grant of WMM then they could add and remove items from a folder, but to rename, move, delete, or modify the permissions on a folder then they would also need an effective grant of WM too. To allow someone to manage the contents of a folder, but not the folder itself, then we just needed to ensure that person had an effective grant of WMM and an effective denial of WM. As an aside, to avoid conflicts, the effective denial would ultimately be coming from a denial to PUBLIC, in combination with grants to appropriate groups, rather than a denial to the user themselves.

WMM Permission Patterns

In explaining some common patterns in the use of the ReadMetadata (RM), WriteMetadata (WM) and WriteMemberMetadata (WMM) permissions on SAS metadata folders, I find the following “truth” table useful:

Row	Effective Permissions			Comment
Row	RM	WM	WMM	Comment
1				-RM, -WM, -WMM: Folder not visible, can’t be modified, contents can’t be modified.
2				-RM, WM, WMM: Folder not visible, any WM and WMM grants are irrelevant.
3
4
5				+RM, -WM, -WMM: Folder and contents visible, folder cannot be modified, folder contents cannot be modified.
6				+RM, -WM, +WMM: Folder and contents visible, folder cannot be modified, folder contents can be modified.
7				+RM, +WM, -WMM: Folder and contents visible, folder can be modified, but folder contents cannot be modified!
8				+RM, +WM, +WMM: Folder and contents visible, folder can be modified, folder contents can also be modified.

When planning for effective permissions the green rows are the ones I aim for. They represent the common patterns, in increasing order of ability, as:

Row 1: Folder not visible to the user
Row 5: Folder and contents visible only
Row 6: Folder contents can be modified but not the folder itself
Row 8: Folder and contents can be modified

The grey rows (2,3,4) are variations on folder-not-visible: any WM and WMM grants are irrelevant because of the RM denial. I try to aim for the row 1 version. I find it looks neater and, when I don’t see any grant ticks, I don’t have to think at all about whether or not any permission is realistically available.

The pattern to avoid is row 7 with the red background. If someone ends up with those effective permissions they are in a confusing situation because they can manipulate the folder but not the folder contents.

WMM Permission Inheritance

The way in which WM and WMM inherit from their parents is a bit different to the other permissions. I find the diagrams below useful when explaining how the RM, WM and WMM permissions are inherited down an inheritance path.

In SAS 9.1.3 it was straightforward. Each permission on a folder, unless specifically set on that folder through an ACT or ACE, would inherit from the same permission on its parent folder:

With the introduction of WMM in SAS 9.2 this changed. Whilst the RM permission continued to inherit from RM in the parent folder, the WM and WMM permissions inherit from each other:

Unless specifically overridden, WM inherits from WMM on the parent folder (except on the root folder which doesn’t have WMM) and WMM inherits from WM on the same folder. You may have noticed WMM following WM when working in the SAS Management Console authorization tab. This might seem complex at first, but when you think about it, it becomes clear why this is necessary. A common pattern for allowing someone to manage a folder’s contents, but not the folder itself, is +RM,-WM,+WMM. With this inheritance model the inherited permissions on any sub-folders created by such a user would be +RM,+WM,+WMM and allow the user to manage any sub-folders they create. However, if the inheritance model was simple, with WM and WMM inheriting from the same parent permissions, that would mean the users permissions on any sub-folders they created would be the same as the parent (+RM,-WM,+WMM). They would be able to create sub-folders but then not have the ability to manage them (delete, rename, move etc) – very strange. This makes it clear to me why the WM/WMM inheritance model needs to be the way it is in SAS 9.2.

SAS Restricted Options on UNIX

In a tweet by Gordon Cox last month, I was reminded of the restricted options facility available with SAS® software on UNIX platforms. This is capability where an administrator can set mandatory SAS system options at multiple levels of granularity: globally, per-group, and/or per-user. The reason for this post is that I don’t look at the documentation for this very often and every time I do it takes me a while to track it down. I always think its going to be in the UNIX companion in the Base SAS area… but it’s not! That gets me every time. Instead it’s tucked away in the Configuration Guide for SAS 9.2 Foundation for UNIX Environments (PDF) in Chapter 2 – Restricted Options. You can find this document in the Install Center section of support.sas.com under SAS Installation Note 36467: Documentation for a SAS® 9.2 installation on UNIX.

The context of the tweet was that the restricted options facility is another mechanism whereby a default setting of the NOXCMD option for SAS platform servers could be overridden for a subset of trusted users or groups in a SAS platform installation. The NOXCMD option is discussed in an earlier post: NOXCMD: NO eXternal CoMmanDs!

A quick summary of restricted options:

SAS Systems Options under UNIX set by an administrator, that cannot be changed by a user
Processed in the order global, group, then user. The last instance of an option is the one that wins.
Global restrictions are read from the file !SASROOT/misc/rstropts/rsasv9.cfg
Group restrictions are read from the file !SASROOT/misc/rstropts/groups/<groupname>_rsasv9.cfg
User restrictions are read from the file !SASROOT/misc/rstropts/users/<userid>_rsasv9.cfg

On Linux (at least) I can use the command “id -gn <userid>” to find out the effective group name for a user, given their user id. For example, “id -gn sassrv” might generate “sas“.

In my SAS 9.2 installation on Linux, whilst everyone else is still constrained by the NOXCMD option, I can ensure that the SAS Enterprise Guide user Bob Baxter, who has a user id of bob, can still use operating system commands in the SAS programs he runs on the SASApp server, by creating the file /usr/local/SAS/SASFoundation/9.2/misc/rstropts/users/bob_rsasv9.cfg with the following contents:

-xcmd

Of course, this only applies to SAS processes launched and run as the requesting user. Whilst it can be used to override NOXCMD for specific users/groups using a standard workspace server, it cant be used to distinguish between different users on the same stored process server, since all users will share SAS stored process server processes running under a shared identity (like sassrv). In that situation directing the users to separate SAS application servers would be more appropriate. There is an example of this in Jim Fenton & Robert Ladd’s SAS Global Forum 2010 paper 311-2010: A Practical Approach to Securing a SAS® 9.2 Intelligence Platform Deployment

Thanks to Gordon for reminding me about the restricted options facility.

Updated SAS Enterprise Guide Admin Paper

One of the papers I regularly recommended to administrators of SAS® Enterprise Guide was TS-788 What SAS® Administrators Should Know about Libraries, Metadata, and SAS® Enterprise Guide 4.1 (PDF), especially for its discussion of the AssignMode extended attribute.

Thanks to a recent post by Chris Hemedinger on The SAS Dummy blog, I’ve discovered that there’s now an updated version of it available: What SAS Administrators Should Know about Libraries, Metadata, and SAS Enterprise Guide (SAS 9.2, SAS Enterprise Guide 4.2 & 4.3) (PDF).

It’s well worth a read and has a great FAQ section at the end. It also mentions METAOUT=DATAREG – new in SAS 9.2.

BTW, if you’re a SAS platform administrator who supports SAS Enterprise Guide users, and you’re not already a reader of The SAS Dummy, I’d definitely recommend adding it to your RSS subscriptions.