Lion Server - Nested sharepoint and/or 'deny' ACL's

Question

Level 1

0 points

Lion Server - Nested sharepoint and/or 'deny' ACL's

I've been having some issues with setting sharepoint & subfolder access for a specific purpose.

The setup is three sharepoints; 'General', 'Management' and 'Finance'.

As expected all employees have access to the 'General' sharepoint, the finance group have access to 'Finance' and the management group have access to everything including the 'Management' sharepoint.

So far so good.

However, there's a requirement to be able to give subcontractors access to specific subfolders in the 'General' sharepoint.

In Snow Leopard you had a number of ways to accomplish this. Either by 'deny' ACL's or simply by making the subfolder a sharepoint of it's own.

However, neither of these options seem to work in Lion Server.

Firstly, 'deny' ACL's does not exist (other than via command line) - I've read that Server app can modify existing deny ACL's, but not create them. I have however not been able to get this to work as I can't seem to see the difference between if an ACL is of 'deny' or 'allow' type via Server app.

Secondly, the 'sharepoint within a sharepoint' does not work if you don't give the user/group access to the topmost sharepoint, which defeats the purpose since the subcontactor is only to access a specific subfolder - not everything above this folder.

Granted, I can set 'read' access for the subcontractor to the 'General' sharepoint and leave 'read' off for any subfolders apart from the one to be accessed and grant the subcontractor 'full control' to that specific folder.

BUT - the problem comes in when a new folder is created within the sharepoint. Due to inheritance, the subcontractor will gain access to any new folders created after the inital setting of permissions.

Here's an example outline of the folder structure:

Red - for subcontractor access

Sharepoint_1

Area_A

A_Project_1

A_Project_2

Area_B

B_Project_1

B_Project_2

B_Subproject_1

B_Subproject_2

B_Subproject_3

Area_C

C_Project_1

C_Project_2

Suggestions for how to accomplis this will be greatly appreciated!

Posted on May 9, 2012 4:35 AM

Reply

Answer 1

Best reply

gracoat

Level 3

673 points

May 9, 2012 6:58 AM in response to eject

Terminal fun!

Use the chmod command to do what your looking for.

sudo chmod +a "contractor deny write" B_Project_2

sudo chmod +a "contractor allow write" B_SubProject_2

sudo chmod +a "contractor deny read" B_SubProject_2

And so on.

Use sudo because your giving permissions that aren't naturally yours.

Chmod is the change permission command.

+a adds an acl. (conversely, -a removes it)

The rest is easy to follow.

HTH

-Graham

Reply

Answer 2

eject Author

Level 1

0 points

May 9, 2012 7:10 AM in response to gracoat

This is definitely useful and I appreciate your reply!

After my initial post, I was actually experimenting with this command.

Unfortunatley it does not acheive the full functionality of what I'm after.

The problem with inherited permissions remain.

If an admin for example adds a new folder under 'B_Broject_2', this new folder will be accessible by the subcontractor because of inheriting the permissions from the 'Area_B' folder (or folders above).

This means the Terminal will have to be invoked every time a new folder is created, which is less than ideal.

Reply

Answer 3

gracoat

Level 3

673 points

May 9, 2012 7:47 AM in response to eject

Ah yes... You need to delete the inherited permission.

But first, make the inherited permissions explicit.

In the Server.app program:

In the server app sidebar, select the server and the click Storage

Select the folder or file whose access permissions you want to change, and then choose edit permissions from the action pop-up menu.

Choose, "Make Inherited Entried Explicit" from the ACtion pop-up menu in the Edit Permissions dialog.

Now go to terminal, and remove the newly explicit permission from the file:

chmod -N filename

Looking at the man page, I see that you can use the -I (capital i) modifier to Remove all inherited entries from the named file(s) ACL(s).

I've never tried this one, but it should work equally as well.

HTH

-Graham

Reply