Metadata permissions conflict

Accepted Solution Solved
Reply
PROC Star
Posts: 1,287
Accepted Solution

Metadata permissions conflict

Hi,

I have a metadata folder X on a BI server, where I have full control (I'm listed by name in the authorizations tab).  Within that folder are two folders, x1 and x2, where I used to have full control.  But suddenly I cannot see folder x1 anymore.  I went to a friend's PC who can still see x1 (friend is in a group that has read access), and can see that somehow my account now has an inherited (grey box around check mark in SMC) ReadMetadata deny and Read deny.  I still have WriteMetadata and Write permission.

So my questions:

1. Since I still have WriteMetadata permission to the folder x1, even though no readmetadata permission, is there a way I can update the permissions myself?  I can't see x1 in SMC.  If there was a way to do a recursive permission change in SMC from folder X to sub-folders and sub-objects, that could work.  Or if I could run some proc to update permissions on X1 that would magically work even without read permission, that would work.

2.  I'm surprised to see that the permissions on X1 say I have an *inherited* (grey box) ReadMetadata deny, even though on X I have ReadMetadata permission.  Does this suggest that the denial was inherited from an ACT or something like that?

Thanks,

--Q.


Accepted Solutions
Solution
‎04-14-2015 04:43 PM
SAS Employee
Posts: 340

Re: Metadata permissions conflict

2. Check if there is a direct ACE or ACT on X1 for a group that you are a member. That group could be SASUSERS or PUBLIC.

If the read deny is assigned via an ACT directly to you, you would see a green background.

1. I think you cannot modify something you cannot see. Having WriteMetadata but no ReadMetadata is an inconsistent setting. Administrators should avoid this setting.

Ask your friend to change the permission for you Smiley Happy

View solution in original post


All Replies
Solution
‎04-14-2015 04:43 PM
SAS Employee
Posts: 340

Re: Metadata permissions conflict

2. Check if there is a direct ACE or ACT on X1 for a group that you are a member. That group could be SASUSERS or PUBLIC.

If the read deny is assigned via an ACT directly to you, you would see a green background.

1. I think you cannot modify something you cannot see. Having WriteMetadata but no ReadMetadata is an inconsistent setting. Administrators should avoid this setting.

Ask your friend to change the permission for you Smiley Happy

PROC Star
Posts: 1,287

Re: Metadata permissions conflict

Thanks very much ,

The background was not green, so I guessed wrong about the potential cause being an ACT.

I was able to solve it with the help of our SAS admin.  Turns out my account had been added to a group which had an explicit deny for the folder.  My guess is that before that I was listed individually (my user name) with indirect/inherited read access (from a parent folder; gray background on check box).  And I guess since the group had explicit deny read access, that trumped my individual indirect read access, and the end result was I was denied read.

Work around for now was I removed myself from the group, gave myself direct/explicit read access (white background, not gray), and then added myself back to the group.  So with that, the direct/explicit read access on my individual account takes precedence over the denial for the group that I'm in.

I guess it makes sense that I can't modify something I can't see.  But I like that I can on Linux.  That is, on Linux, I'm the owner of the files I create.  So even if I accidentally do something crazy that removes my read access (chmod ugo-rwx myfile.txt) , I can still chmod it back since I'm still the owner.  That feels like a nice safety net.

Thanks again,

--Q.

PROC Star
Posts: 402

Re: Metadata permissions conflict

Hi Quentin,

To help avoid this type of problem again in future, you could let your admin know that they might want to consider only ever denying permissions to the implicit groups (SASUSERS & PUBLIC) and then granting access back to those groups that need access.  I provide an example of this type of problem in a paper I did a few years back, in which 2 users were members of exactly the same groups (by different mechanisms) and one could see a folder and one could not. See Best Practices with SAS9 Metadata Security Presentation at SFANZ 2010 and the example in Slides 15 & 16: Wide Denials, Narrow Grants. There is also an excellent SAS Global Forum 2011 paper by Cecily Hoffritz & Johannes Jørgensen, Best Practice Implementation of SAS® Metadata Security at Customer Sites in Denmark http://support.sas.com/resources/papers/proceedings11/376-2011.pdf that covers this practice, as well as several others that will make SAS metadata security much easier if they are followed. I thoroughly recommend every SAS platform admin familiarize themselves with that SASGF11 paper.

If you or your admin are going to SASGF15, and would like to talk about this some more, please pop by the Metacoda stand in The Quad. I can also show you some new metadata security recommended practice tests that we have to detect these and several other types of issues.

Cheers

Paul

PROC Star
Posts: 1,287

Re: Metadata permissions conflict

Thanks much for the links, Paul.  I will definitely review these.  Sadly, I won't be at SGF this year, but I've already circled my calendar for 2016 in Vegas, so hope to take you up on your offer next year (and finally attend my first Metacoda / Zencos Tweetup !)

If I could impose for another thought, I suppose I've probably backed myself into a poor position by my choice of metadata folder structures.  I'm doing development work and test work on the same instance.  I've got folders like:

/Project1

     /Dev

     /Test

/Project2

     /Dev

     /Test

(I expect that structure will make admins, including my own, shudder... : )

So currently, I give the project1 group (users) read access to Project1, and then they inherit read access to /Test so that they can run the stored processes etc in there.  But since I don't want the users to see /Dev, I give the group an explicit deny to /Dev.  And I give just myself full control of Dev (by giving myself full control of Project1 and Dev).

Of course ideally I would have separate server contexts for /Dev and /Test.  But for now (on one context), maybe my metadata security life would be easier if I switched to:

/Dev

     /Project1

     /Project2

/Test

     /Project1

     /Project2

That way I could follow the rule of wide denials and narrow grants.  And it's just one grant to me for /Dev, one grant for me to /Test, and one grant to a group for each project to /Test/ProjectX

Sound reasonable?

Thanks again,

--Q.

PROC Star
Posts: 402

Re: Metadata permissions conflict

Certainly the second structure could be secured with fewer access controls, but that doesn't mean the first structure is bad. If it's what the business requires, it just needs securing differently - and if you use ACTs instead of ACEs it becomes more manageable.

I would look at something like this for structure 1:

/Project1: apply "Hide ACT" + ACEs: Project1Users: +RM, +R and Developers: +RM, +R

     /Dev: re-apply "Hide ACT" + ACEs: Developers: +RM, +R, +WMM

     /Test: apply ACEs: Project1Users: +RM, +R, +WMM and Developers: +RM, +R, +WMM

/Project2: apply "Hide ACT" + ACEs: Project2Users: +RM, +R and Developers: +RM, +R

     /Dev: re-apply "Hide ACT" + ACE: Developers: +RM, +R, +WMM

     /Test: apply ACEs: Project2Users: +RM, +R, +WMM and Developers: +RM, +R, +WMM

You can find the definition of "Hide ACT" and "Protect ACT" in the Baseline ACTs section of the SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition. Instead of using ACEs (explicit permissions) for the supplemental grants you could put them into ACTs and apply the ACTs to avoid the repetition. In the example above, the project and developers groups can add content to the Test folder. If you want them to be read-only then take out the WMM grant(s).

.. and alternatively something like this for structure 2:

/Dev: apply "Hide ACT" + ACEs: Developers: +RM, +R

     /Project1: apply ACEs: Developers: +WMM

     /Project2: apply ACEs: Developers: +WMM

/Test:

     /Project1: apply "Hide ACT" + ACEs: Project1Users: +RM, +R, +WMM and Developers: +RM, +R, +WMM

     /Project2: apply "Hide ACT" + ACEs: Project2Users: +RM, +R, +WMM and Developers: +RM, +R, +WMM

How does that look?

PROC Star
Posts: 1,287

Re: Metadata permissions conflict

Looks very nice.  Thanks again.  Plenty for me to chew on.

🔒 This topic is solved and locked.

Need further help from the community? Please ask a new question.

Discussion stats
  • 6 replies
  • 1001 views
  • 8 likes
  • 3 in conversation