On Tue, Mar 8, 2011 at 9:58 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Tue, 8 Mar 2011 09:55:08 -0600 > Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > >> 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? > > I'd leave it all up to the server and just pass it through. > >> Meanwhile if the command succeeds, cifs client should simply >> invalidate inode metadata? > > That sounds reasonable. If you're sure it can't change ownership, then > you could consider doing that only when cifsacl is enabled, but it's > probably safest to just invalidate it unconditionally. I can't imagine > that this will be a commonly used codepath anyway. I think invalidating on setacl sucess for the case when cifsacl enabled makes sense. -- Thanks, Steve -- 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
