Odd behaviour of file system access API

[John Beranek - PA]

I've just configured access to our Isilon clusters via the file system access API to allow a particular system to read/write files from the Isilon via the API.

What I discovered is odd behaviour regarding ACE inheritance.

The directory structure I am allowing access to has a number of ACEs set on it, to allow the directory structure to be viewed/modified by administrators.

Now, when the API is used by the fairly restricted API user (only has access via API, no other access), inheritance appears to be followed:

$ ls -led test_api

drwxrwx--- +  2 svc_api-access  domain users  21 Nov 11 13:22 test_api

 OWNER: user:svc_api-access

 GROUP: group:domain users

 CONTROL:dacl_auto_inherited,sacl_auto_inherited

 0: user:svc_api-access allow inherited dir_gen_read,dir_gen_write,dir_gen_execute,std_delete,object_inherit,container_inherit,inherited_ace

 1: group:dl_rba_smbroots-fullcontrol allow inherited dir_gen_all,container_inherit,inherited_ace

However, when a file is created in this directory, most* inheritable ACEs are ignored:

$ ls -led test_api/foo

-rwx------ +  1 svc_api-access  domain users  15 Nov 11 13:22 test_api/foo

 OWNER: user:svc_api-access

 GROUP: group:domain users

 CONTROL:dacl_auto_inherited,sacl_auto_inherited

 0: user:svc_api-access allow file_gen_read,file_gen_write,std_write_dac

 1: group:domain users allow std_read_dac,std_synchronize,file_read_attr

 2: everyone allow std_read_dac,std_synchronize,file_read_attr

 3: user:svc_api-access allow inherited file_gen_read,file_gen_write,file_gen_execute,std_delete,inherited_ace

I say "most" ACEs were ignored, because the ACE for the user "svc_api-access" actually was inherited. However, along with that, a set of ACEs for essentially 'UGO' have been created, and the "dl_rba_smbroots-fullcontrol" ACE has been ignored.

I can't see anything in the "put file" documentation which would change inheritance behaviour, only a very vague mention of the "x-isi-ifsaccesscontrol" option.

Now, you can modify an existing file to apply a set of ACEs, but surely you shouldn't need to write a file, and then (re-)apply the ACEs that said file should have had by inheritance!?

Does anyone have significant experience of the file system access API who could point me in the right direction?

Cheers,

John

[John Beranek - PA]

One addendum to my post, the first "ls -led" is showing the permissions on a directory created by the API user.

John

[Peter Serocka]

Have you passed any value with "x-isi-ifsaccesscontrol"?

Looks like it accepts the UNIX permission bits in octal notation.

When attempting to set  UNIX permissions a la chmod 

on a file with an ACL the bits can either override the ACL

or get merged, or even be ignored... depending on 

some setting in OneFS:

https://community.emc.com/message/912029#912029 

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.

[John Beranek - PA]

No, I've not sent the x-isi-ifs-access-control header at all.

However, I don't understand what value that header should have if I don't want it to make any ACL changes at all...

I've just noticed that the failure to inherit the dl_rba_smbroots-fullcontrol ACE was actually my fault. For some reason the top-level directory had 'container_inherit' but not 'object_inherit'. Now that is fixed, newly created files do at least get all the inheritable permissions, but they still get the extra "UGO"/POSIX style ACEs added.

John

[Peter Serocka]

On 2015 Nov 13 Fri, at 20:20, John Beranek - PA <john.b...@pressassociation.com> wrote:

> No, I've not sent the x-isi-ifs-access-control header at all.
>

> However, I don't understand what value that header should have if I don't want it to make any ACL changes at all…

Good question! Unless/until you can get this information
out of EMC support, here are some approaches to reverse engineering...

- what happens with x-isi-ifs-access-control=“0000” ?

- what happens if you set the Isilon to ignore UNIX chmods of ACL
(see the link I sent earlier; might use a virtual Isilon for testing)

- is the behaviour you are seeing with the API identical
to the effect of any sequence of operations executed directly
on the Isilon, like for example:
1. create new file as root / as user
2. chown file to user (if 1. done as root)
3. chmod UNIX bits as sent with x-isi-ifs-access-control,
or chown some default bits like 0777 or 0755 ?
(absence of x-isi-ifs-access-control /could/ mean that
a default is supplied; NASTY, but have seen stranger things….)

— Peter

[Peter Serocka]

On 2015 Nov 13 Fri, at 20:20, John Beranek - PA <john.b...@pressassociation.com> wrote:

> No, I've not sent the x-isi-ifs-access-control header at all.
>

> However, I don't understand what value that header should have if I don't want it to make any ACL changes at all…

Good question! Unless/until you can get this information
out of EMC support, here are some approaches to reverse engineering...

- what happens with x-isi-ifs-access-control=“0000” ?

- what happens if you set the Isilon to ignore UNIX chmods of ACL
(see the link I sent earlier; might use a virtual Isilon for testing)

- is the behaviour you are seeing with the API identical
to the effect of any sequence of operations executed directly
on the Isilon, like for example:
1. create new file as root / as user
2. chown file to user (if 1. done as root)
3. chmod UNIX bits as sent with x-isi-ifs-access-control,
or chown some default bits like 0777 or 0755 ?
(absence of x-isi-ifs-access-control /could/ mean that
a default is supplied; NASTY, but have seen stranger things….)

— Peter

>

[John Beranek - PA]

On Friday, 13 November 2015 16:29:10 UTC, Pete wrote:

On 2015 Nov 13 Fri, at 20:20, John Beranek - PA <john.b...@pressassociation.com> wrote:

> No, I've not sent the x-isi-ifs-access-control header at all.
>
> However, I don't understand what value that header should have if I don't want it to make any ACL changes at all…

Good question! Unless/until you can get this information
out of EMC support, here are some approaches to reverse engineering...

Well,  both sending x-isi-ifs-access-control as 0000 and performing "chmod 0000" lead to the same results, namely ACEs:

 0: user:test_user allow std_read_dac,std_write_dac,std_synchronize,file_read_attr,file_write_attr

 1: group:domain users allow std_read_dac,std_synchronize,file_read_attr

 2: everyone allow std_read_dac,std_synchronize,file_read_attr

So, apparently a default set of permissions is being applied whenever a file is added via the API.

John