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:
|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.|
|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.
2 thoughts on “WriteMemberMetadata Permission”
Thanks for a very timely post!
We had problem here at an install where we had multiple Application Servers, and could not work out why users could connect to one, but not the other. Turned out one Application Server had WMM set, the other WMM cleared. Setting both fixed the problem – clearly the act of connecting to an Application Server requires WMM.
Thanks for your comment and sharing your experiences. I am wondering if I have either misunderstood you or whether it was a permission other than WriteMemberMetadata that was the underlying cause? I ask because the WMM permission only applies to folders. WMM can’t be set on an application server (e.g. SASMeta, SASApp etc) as the only applicable permissions for an application server are RM, WM and A – they are the only ones you can see in the authorization tab on an application server. You would certainly need RM to see and use an application server. You can hide an application server from a user if they have an effective denial of RM on it. Additionally some of those users, that might need to assign libraries to an application server for example, will also need an effective grant of WM too.