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. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
