How does UserAcl work for namespace paths?

There's not a way for objects to inherit the ACLs set on parent directories unfortunately.

Are you trying to provide access to objects from different subtenants?

One thing worth mentioning:  directories are objects in Atmos.  You can set metadata, ACLs, etc on directories just as you can file objects.

Raj

Aha! I didn't see an API option to set the ACL for a directory, just for objects. But it appears to work for directories also.

It would still be nice to have it work for the entire path in one go.

Thanks.

On page 38 of the EMC Atmos Version 1.4.1 Programmer’s Guide it states that

"For namespace access, a filename or directory name is sufficient;
optionally, a full pathname (for either a file or directory) can be
specified. In a create operation, if the pathname contains nonexistent
directories, they are created automatically. The ACL specified in the
request is applied to all newly created objects (files or directories)."

But that's not what happens. When I specify the UserAcl to be FULL_CONTROL for a second userid, that userid cannot look at the directories that were created, nor can it create a new object in that directory. It can, however, update the object.

If the first user subequently issues an 'acl' command on the directory, it then becomes visible to the second user.

So I guess my real question is, is the manual wrong? Or is this a bug?

Do I need to explicitly set ACL on directories, or should the ACL of the directories be set when they are created?

You do indeed need to be explicit about setting ACLs on directories.  That particular section of text ends with:

"The metadata specified in the request is applied only to the leaf object (a file or directory)."

To be clear it should really read:

"The metadata and ACLs specified in the request are applied only to the leaf object (a file or directory)."

Raj

It seems that the statement  I quoted also needs some work:

     "The ACL specified in the request is applied to all newly created objects (files or directories)."

It should actually read something like:

     "The ACL specified in the request is not applied to all newly created objects (files or directories), but only to the leaf object (a file or directory)."

Are you sure this isn't a bug?

You're right --- it definitely could be even clearer.

When the line states "... all newly created objects (files or directories)" --- it's intended to mean that newly created objects (files or directories) in that request get the ACL applied to the leaf --- not subsequent requests.

So in this request:

POST /rest/namespace/dir1/file.txt HTTP/1.1
X-Emc-Useracl: NA000FBBFEd87e76aded=FULL_CONTROL
X-Emc-Signature: Ei4iG8ivxIBhYeM9uOze/Err1Jc=
Host: accesspoint.emccis.com
Date: Wed, 06 Apr 2011 19:01:03 GMT
X-Emc-Uid: d131c2805d244b1a9e91aefb4b545ebc/NA000FBBFE5BE6CEBFBE
Content-Type: application/octet-stream
X-Emc-Date: Wed, 06 Apr 2011 19:01:03 GMT

There is a newly created object called file.txt and the ACL specified in the request is set on that object.

Just to be sure I walked up and chatted with the web services engineer responsible and this indeed the way it works.

Raj

You seems to be agreeing with me, but also seem to be missing my point.

I am making a single request that is supposed to be creating multiple objects, some directoies along a path and a file. My single request creates the new directories, I am not making multiple requests, and yet, the directories are not getting the ACL as specified in the request.

The document clearly states:

... a  full pathname (for either a file or directory) can be specified. In a  create operation, if the pathname contains nonexistent directories, they  are created automatically. The ACL specified in the request is applied to all newly created objects (files or directories).

That is not unclear, that is blatantly wrong. 'is applied to ALL newly created objects' does not imply that it is applied to just the leaf.

A simple example is that when I start with a blank slate and create /dir1/file1.txt, it will create two new objects, a file1.txt and a directory dir1.

file1.txt which is newly created has the correct UserACL, and dir1 which is also newly created by the same request, does not get the same ACL.

*** REQUEST *** POST /rest/namespace/dir1/file1.txt Date: Wed, 06 Apr 2011 20:46:04 GMT Accept: */* User-Agent: libwww-perl/5.831 Content-Length: 1024 Content-Type: application/octet-stream X-Emc-Date: Wed, 06 Apr 2011 20:46:04 GMT X-Emc-Uid: DevelImport X-Emc-Useracl: DevelRetrieve=FULL_CONTROL *** RESPONSE *** HTTP/1.1 201 Created Connection: close Date: Wed, 06 Apr 2011 20:46:05 GMT Location: /rest/objects/4d8b86c0a11ad09d04d8b9355a0b5304d9cd10d586b1 Server: Apache Content-Length: 0 Content-Type: text/plain; charset=UTF-8 Client-Date: Wed, 06 Apr 2011 20:46:04 GMT Client-Peer: 172.26.208.152:443 Client-Response-Num: 1 X-Emc-Delta: 1024 X-Emc-Policy: default *** REQUEST *** GET /rest/namespace/dir1/?acl Date: Wed, 06 Apr 2011 20:46:04 GMT Accept: */* User-Agent: libwww-perl/5.831 Content-Type: application/octet-stream X-Emc-Date: Wed, 06 Apr 2011 20:46:04 GMT X-Emc-Uid: DevelImport *** RESPONSE *** HTTP/1.1 200 OK Connection: close Date: Wed, 06 Apr 2011 20:46:05 GMT Server: Apache Content-Length: 0 Content-Type: text/plain; charset=UTF-8 Client-Date: Wed, 06 Apr 2011 20:46:04 GMT Client-Peer: 172.26.208.152:443 Client-Response-Num: 1 X-Emc-Groupacl: other=NONE X-Emc-Policy: _int X-Emc-Useracl: DevelImport=FULL_CONTROL *** REQUEST *** GET /rest/namespace/dir1/file1.txt?acl Date: Wed, 06 Apr 2011 20:46:04 GMT Accept: */* User-Agent: libwww-perl/5.831 Content-Type: application/octet-stream X-Emc-Date: Wed, 06 Apr 2011 20:46:04 GMT X-Emc-Uid: DevelImport *** RESPONSE *** HTTP/1.1 200 OK Connection: close Date: Wed, 06 Apr 2011 20:46:05 GMT Server: Apache Content-Length: 0 Content-Type: text/plain; charset=UTF-8 Client-Date: Wed, 06 Apr 2011 20:46:04 GMT Client-Peer: 172.26.208.152:443 Client-Response-Num: 1 X-Emc-Groupacl: other=NONE X-Emc-Policy: _int X-Emc-Useracl: DevelImport=FULL_CONTROL, DevelRetrieve=FULL_CONTROL

I'm definitely in agreement --- we need to update the documentation to accurately reflect the behavior.

I've sent a note over to the folks responsible.

Thanks,

Raj

While I agree that getting the documentation to match the behavior is a good thing, I would like to point out that what I was really hoping to get out of this was that the behavior would match the documentation.

Having the ACL for the directories along the path match the ACL for the leaf object was a really neat and cool feature. It's disappointing that it was not, in fact, a feature.

If it is in fact desirable to have permissions only apply to leaf objects, then I would sugest that having a different create command that applied to all newly created objects, as suggested in the manual, would be a really neat option to have.

What I'm saying is, don't fix the manual to match the api if the better resolution (from the viewpoint of the user) is actually to fix the api to match the manual.

Sent you a private message with my contact information so that we can chat.

I'd love to understand the specific requirements to be able to take this to Product Management.