Metadata permissions

[Nigel_Pain]

I've discovered a flaw in the access control model we have for our metadata.

We have a large number of libraries saved (mostly) in their own metadata folders within /Shared Data, and ACTs are applied to those locations to ensure that only authorised users may view/update data within them. Up to a year ago this worked fine because nobody explicitly used metadata folders, simply saving and querying data sets within metadata-defined libraries. However, we got a new SAS infrastructure last year, which included Visual Analytics. As a result, users are explicitly creating VA reports within metadata folders.  I've now realised that the permissions on /Shared Data itself are inherited from the Default ACT, which grants SASUSERS RM,WM,WMM and CM. This means that any user may save their reports directly into /Shared Data. The easiest way to stop this would be to remove the WM grant from the Default ACT but I don't know if this would have any unexpected and undesirable consequences.

Does anyone have any thoughts on this?

Many thanks.

[Patrick]

I normally create my own top folder(s) with depending on the use case either the name of the company/high level functional area or the project/solution.

Would it still be an option for you to reorganize your metadata in such a manner or would that already impact to heavily on existing VA reports?

[Nigel_Pain]

It would be a nice idea but potentially disruptive. Although actual VA usage isn't very large at the moment, there are around 230 folders, with contents, which I would have to move to a new top-level folder. And I would presumably have to modify the VA.Default.MetadataFolder value manually in the extended attributes of all the LASR libraries?

Alternatively, would there be any dangers to assigning a new ACT to the /Shared Data folder denying the write permissions to SASUSERS?

[PaulHomes · Accepted solution]

Hi Nigel,

i would advise against removing the SASUSERS: +WM from the repository ACT (commonly Default ACT). From memory I believe that those broad grants of +RM and +WM to SASUSERS at the repository level control the ability to log in and create new objects (which all SAS users need to do) - I can't find any explicit documentation on this so I'll double check and test it when I get a chance.

If you look at the Adjust the Repository-Level Settings section in the SAS 9.4 Management Console: Guide to Users and Permissions, it states "All users need ReadMetadata and WriteMetadata access at the repository level. In general, it is appropriate for the SASUSERS group to have these permissions on the repository ACT's Permission Pattern tab."

What I would recommend instead is that you use something like a "Hide ACT" to revoke WM from all users except admins and selectively grant WM (or WMM) back to those that require it with additional ACTs. For more info on this see the Baseline ACTs section in the SAS 9.4 Intelligence Platform: Administration Security Administration Guide. If you haven't already seem them, I would also wholeheartedly recommend reading David Stern's excellent Five papers on Recommended SAS 9.4 Security Model Design (part 1 & part 2).

I hope this is useful.

Cheers
Paul

[Nigel_Pain]

Thank you Paul, that answers my question, and confirms my worries about modifying the Default ACT. I'll apply an extra ACT to /Shared Data, denying WM and WMM to SASUSERS. By far the easiest and safest option, too.

Thanks also for the recommendation on David's papers. He worked with us to set up our metadata security model (and migrate the metadata from 9.1.3) when we moved to 9.3 some years back. Top man!

[PaulHomes]

No worries Nigel. Good to hear it helped. Thanks for marking the post solved too.