Recursively apply NTFS permissions "implicitly"

[John Beranek - PA]

I'm looking to apply some new NTFS permissions to a large directory structure, and have found that performing this operation from a Windows machine can be a very time-consuming process.

Therefore I thought that the procedure could be a lot quicker from the Isilon shell, using chmod.

The issue I've found is that "chmod -R" appears to add permissions to each filesystem object explicitly, not implicitly, as Windows does.

i.e. If I start with a directory, "test_dir" with the permissions:

$ ls -led test_dir

drwxrwx--- +  5 johnb  domain users  59 Nov 20 09:31 test_dir

 OWNER: user:johnb

 GROUP: group:domain users

 CONTROL:dacl_auto_inherited,sacl_auto_inherited

 0: group:smbroots-fullcontrol allow inherited dir_gen_all,object_inherit,container_inherit,inherited_ace

Then, create some directories/files underneath it:

$ mkdir -p test-dir/1/2/3

Then, apply a new permission, using "chmod -R":

$ chmod -R +a user joeb allow generic_all,object_inherit,container_inherit test_dir

I then find that the 'joeb' permissions have been applied, but explicitly, not using any inheritance:

$ ls -led test_dir/1

drwxrwx--- +  3 johnb  domain users  19 Nov 20 09:31 test_dir/1

 OWNER: user:johnb

 GROUP: group:domain users

 CONTROL:dacl_auto_inherited,sacl_auto_inherited

 0: user:joeb allow dir_gen_all,object_inherit,container_inherit

 1: group:smbroots-fullcontrol allow inherited dir_gen_all,object_inherit,container_inherit,inherited_ace

Is there any way to recursively apply permissions, with inheritance?

Cheers,

John

[Peter Serocka]

The "implicit" inheritance only takes place 

when new files are created....

If you are mainly concerned with finishing

the ACL update quickly, have a look at the

OneFS PermissionRepair job. Kind of

a parallel "chmod -R", but less flexible.

It can only set *identical* permissions/ACLs 

for all objects in a subtree.

hth

-- Peter

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Peter Serocka

CAS-MPG Partner Institute for Computational Biology (PICB)

Shanghai Institutes for Biological Sciences (SIBS)

Chinese Academy of Sciences (CAS)

320 Yue Yang Rd, Shanghai 200031, China

pser...@picb.ac.cn

[John Beranek - PA]

Thanks for your reply.

In this case, applying identical permissions is no good, because the directory in question is a tree of users' storage, where each user only has rights to their own directory...

So, I'm left with applying the permissions from a Windows system, which does "do the right thing"?

John

[Peter Serocka]

On 2014 Nov 20. md, at 18:33 st, John Beranek - PA wrote:

Thanks for your reply.

In this case, applying identical permissions is no good, because the directory in question is a tree of users' storage, where each user only has rights to their own directory...

Yep :(

So, I'm left with applying the permissions from a Windows system, which does "do the right thing"?

I'd be suprised to see the final effect on the ACLs

being much different for Windows vs chmod -R.

Running times should also be comparable,

if not in favour of chmod.

Peter

[John Beranek - PA]

The permissions applied by Windows are definitely different. If you apply permissions on a directory, it will implicitly apply permissions down the tree, but if you use "chmod -R" on the Isilon, permissions are set explicitly on every file and directory.

Cheers,

John

[Peter Serocka]

On 2014 Nov 20 Thu, at 18:51, John Beranek - PA <john.b...@pressassociation.com> wrote:

> The permissions applied by Windows are definitely different. If you apply permissions on a directory, it will implicitly apply permissions down the tree,

I’m curious, what does ls -led show on the Isilon then?

Peter

[John Beranek - PA]

An example from applying a new permission (joshb, Windows "Modify" rights) to the test directory from Windows:

$ ls -led test_dir

drwxrwx--- +  5 johnb  domain users  59 Nov 20 09:31 test_dir

 OWNER: user:johnb

 GROUP: group:domain users

 CONTROL:dacl_auto_inherited,sacl_auto_inherited

 0: user:joeb allow dir_gen_all,object_inherit,container_inherit

 1: user:joshb allow dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit

 3: group:smbroots-fullcontrol allow inherited dir_gen_all,object_inherit,container_inherit,inherited_ace

$ ls -led test_dir/1/2

drwxrwx--- +  2 johnb  domain users  0 Nov 20 09:19 test_dir/1/2

 OWNER: user:johnb

 GROUP: group:domain users

 CONTROL:dacl_auto_inherited,sacl_auto_inherited

 0: user:joeb allow dir_gen_all,object_inherit,container_inherit

 1: group:smbroots-fullcontrol allow inherited dir_gen_all,object_inherit,container_inherit,inherited_ace

 2: user:joshb allow inherited dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit,inherited_ace

John

[Peter Serocka]

Thanks! The inherited ACEs still get written to each ACL,
which takes its time as you noted.

If you want to give certain users or group
root-like powers, with Isilon you can do this directly
on share level, have you seen this?
No need to modify the files’s ACLs in that case.

Peter

[Dan Pritts]

Pretty sure that you can use the inherited_ace flag with chmod -RE.  You'd just have to then go and remove it from the top level. 

cat <<EOF | chmod -RE
user joeb allow generic_all,object_inherit,container_inherit

group smbroots-fullcontrol allow inherited dir_gen_all,object_inherit,container_inherit,inherited_ace

user joshb allow inherited generic_read,generic_write,generic_execute,std_delete,object_inherit,container_inherit,inherited_ace
EOF

I don't recall the exact "generic" rights to apply to get what you're after, but you get the idea.  Also not sure about the inherit stuff, what will it do with files?  But again, hopefully you get the idea.

Hmm, looking at the script I wrote for this circumstance, I have two ACE's, as such, presumably to handle the inherit flags. 

"user $ACLUSER allow generic_all\n",
"user $ACLUSER allow generic_all,object_inherit,container_inherit\n",

I am not a windows expert by any means, but this seems to work in practice.   I am totally willing to believe that I've got something wrong, so tread lightly.

Hope this helps. 

danno

John Beranek - PA

November 20, 2014 at 7:31 AM

An example from applying a new permission (joshb, Windows "Modify" rights) to the test directory from Windows:

$ ls -led test_dir

drwxrwx--- +  5 johnb  domain users  59 Nov 20 09:31 test_dir

 OWNER: user:johnb

 GROUP: group:domain users

 CONTROL:dacl_auto_inherited,sacl_auto_inherited

 0: user:joeb allow dir_gen_all,object_inherit,container_inherit

 1: user:joshb allow dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit

 3: group:smbroots-fullcontrol allow inherited dir_gen_all,object_inherit,container_inherit,inherited_ace

$ ls -led test_dir/1/2

drwxrwx--- +  2 johnb  domain users  0 Nov 20 09:19 test_dir/1/2

 OWNER: user:johnb

 GROUP: group:domain users

 CONTROL:dacl_auto_inherited,sacl_auto_inherited

 0: user:joeb allow dir_gen_all,object_inherit,container_inherit

 1: group:smbroots-fullcontrol allow inherited dir_gen_all,object_inherit,container_inherit,inherited_ace

 2: user:joshb allow inherited dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit,inherited_ace

--
Dan Pritts
ICPSR Computing & Network Services
University of Michigan
+1 (734)615-7362

[Peter Serocka]

Really tricky...

The point is that "inherited_ace" is just an indicator for 

occured inheritance, in order to block the affected ACE

from getting individually modified (which would break

inheritance). Thus it can't be set explicitly.

What would be cool to have is a way to set

the "to-be-inherited" ACE(s) on the toplevel direcory,

and then just "propagate" them down the tree.

"As if" the subdirectories and files would have been 

freshly created.

It would still require a recursive walk,

but the syntax could be much simpler, like:

chmod -R --propagate--all-inherited-ACEs topleveldir/      # no actual ACEs given here!

Just it seems that no such tool/option exists

in the UNIX world, but there is one in Windows.

-- Peter

--
You received this message because you are subscribed to the Google Groups "Isilon Technical User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isilon-user-gr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Beranek - PA]

Well, Dan's advice certainly appears to work...at least mostly.

Where it's a little suspect is that it's possible to create apparently inherited ACEs on objects which aren't really inherited. These ACEs are then not changeable/removable from a Windows client.

Cheers,

John

[Dan Pritts]

I wonder then how windows "knows" that the ACE's aren't "really"
inherited." Huh.

John Beranek - PA wrote:

> Well, Dan's advice certainly appears to work...at least mostly.
>
> Where it's a little suspect is that it's possible to create apparently
> inherited ACEs on objects which aren't really inherited. These ACEs
> are then not changeable/removable from a Windows client.
>

[LinuxRox]

John,

what command/process did you end up using ?

[John Beranek - PA]

What I ended up with was something like:

chmod -R +a user testuser allow generic_read,generic_write,generic_exec,std_delete,object_inherit,container_inherit,inherited_ace test_dir

chmod +a user test allow generic_read,generic_write,generic_exec,std_delete,object_inherit,container_inherit test_dir

chmod -a user testuser allow dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit,inherited_ace test_dir

This applies the permission recursively while setting the inheritance bit, then sets the same permission at the top-level without inheritance and finally removes the inherited permission from the top-level.

Cheers,

John

[John Beranek - PA]

The result as seen from Windows, with a little bit of redacting...

Cheers,

John

[Alexandra Harker]

I've been managing Windows permissions through chmod for over a year now. I struggled with the same thing, and I hope I help with your question to some degree. I wrote a blog post on it, but my blog is indisposed right now, so here's the short of it:

To add permissions recursively-

chmod -R +a [user/group] "[domain]\\[username/groupname]" [allow/deny] [permissions (see below)] [directory]

Read only:

allow dir_gen_read,dir_gen_execute,object_inherit,container_inherit 

Modify:

allow dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit 

Full Control:

allow generic_all,object_inherit,container_inherit

To remove, was a little trickier to find out, because you have to run the chmod -R -a twice. Once to break the inheritance and once to remove the ACE. And you have to change the permissions specified on the command to reflect the inheritance, and once its gone, without.

I haven't had issues yet, but we might not be handling permissions in the same way your environment does. Please let me know if you have questions (or improvements). :) I really hope this helps.

PS,

In my opinion, PermissionRepair only works as a feasibly solution when you are trying to clone a directory's permissions. I haven't had any luck with it recursively, and unless the permissions are the same throughout the structure, you'll end up causing more damage than its worth.