On Tue, Mar 8, 2011 at 9:43 AM, Shirish Pargaonkar
<shirishpargaonkar@xxxxxxxxx> wrote:
> On Tue, Mar 8, 2011 at 9:22 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>> On Tue, 8 Mar 2011 09:17:48 -0600
>> Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote:
>>
>>> On Tue, Mar 8, 2011 at 8:32 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
>>> > On Mon, 7 Mar 2011 23:00:25 -0600
>>> > shirishpargaonkar@xxxxxxxxx wrote:
>>> >
>>> >> From: Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx>
>>> >>
>>> >>
>>> >> Allow setting cifs_acl on the server.
>>> >> Pass on to the server the ACL blob generated by an application.
>>> >> cifs is just a pass-through, server decides whether to enforce/apply
>>> >> the ACL blob composed by an application.
>>> >>
>>> >>
>>> >> Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx>
>>> >
>>> > Seems sane enough and is probably more useful than trying to map all of
>>> > this to POSIX acl's and modes. I wonder though...if you do this, then
>>> > the permissions and possibly ownership change. Do you need to
>>>
>>> owner/group will not change, only the ACL (DACL).
>>>
>>
>> So I can't change group ownership on the file by modifying the DACL?
>>
>
> ACL is a list of ACEs and owner and group do not qualify as an ACE.
>
>> Also, while I don't particularly like the cifsacl acl-to-mode mapping
>> code, it still exists. If someone changes the ACL, don't you need to
>> account for the possibility that the mode has also changed?
>
> yes. Should invalidate the inode metadata as you stated earlier.
>
>>
>> --
>> Jeff Layton <jlayton@xxxxxxxxxx>
>>
>
# smbcacls
Usage: smbcacls [-?] [-?tV] [-?tV] [-?tVNkPe] [-?|--help] [--usage]
[-D|--delete ACL]
[-M|--modify ACL] [-a|--add ACL] [-S|--set ACLS] [-C|--chown USERNAME]
[-G|--chgrp GROUPNAME] [--numeric] [-t|--test-args]
Not sure what the tool would generate the "ACL blob" would_be/would_do!
Should cifs module check what the blob contains or just strictly act
as a pass-through
and let server decide?
Meanwhile if the command succeeds, cifs client should simply
invalidate inode metadata?
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
