On Tue, 30 Aug 2011 09:03:05 -0500 Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > On Mon, Aug 29, 2011 at 7:29 PM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > > On Mon, 29 Aug 2011 16:24:33 -0500 > > Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > > > >> On Tue, Aug 23, 2011 at 8:15 AM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > >> > On Mon, 22 Aug 2011 08:33:49 -0500 > >> > Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > >> > > >> >> On Fri, Aug 12, 2011 at 11:33 AM, <shirishpargaonkar@xxxxxxxxx> wrote: > >> >> > From: Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> > >> >> > > >> >> > > >> >> > Add mount option backup. > >> >> > > >> >> > It allows an authenticated user to access files with the intent to back them > >> >> > up including their ACLs, who may not have access permission but has > >> >> > "Backup files and directories user right" on them (by virtue of being part > >> >> > of the built-in group Backup Operators. > >> >> > > >> >> > If an authenticated user is not part of the built-in group Backup Operators > >> >> > at the server, access to such files is denied. > >> >> > > >> >> > > >> >> > Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> > >> >> > --- > >> >> > >> >> > >> >> Jeff, Steve, > >> >> > >> >> Any comments on this patch (and manpage patch in cifs-utils)? > >> >> > >> > > >> > This seems like a really nasty kludge. It doesn't seem like the > >> > implications of this have been carefully considered. > >> > > >> > What happens I mount with the "backup" flag and do not have the > >> > necessary permissions on the server to use the flag in an open? Will > >> > this new flag be mutually exclusive with "multiuser"? > >> > > >> > One idea that might be better is to come up with way to mark certain > >> > (unix) users with the appropriate flag. If all the backup users were in > >> > a certan group, for instance, then you could use that info to decide > >> > whether to set the flag in the open calls. > >> > > >> > -- > >> > Jeff Layton <jlayton@xxxxxxxxx> > >> > > >> > >> Jeff, one comment, it is not the (unix) user that matters, it is the > >> user on the server (authenticated) user at the server because the > >> user right to access a file in backup mode can be granted only > >> to a user at the server. > >> > > > > Right, I realize that. > > > >> I think care should be taken to make sure that backup and > >> multiuser are mutually exclusive mount options in mount.cifs. > >> > > > > My objection here is more fundamental... > > > > This patchset lends itself to a single, specific use. You can create a > > mount that you want to use for backups. Typically, when running backups > > like this you also intend for this mount to be used by only one (unix) > > user. > > > > Adding a "backup" option is tantamount to adding extra privileges to > > this mount for anyone who accesses it. However, it's not clear to me > > how these extra privileges will be secured from other users that don't > > necessarily need them. > > > > It seems to me that it would be far more useful to find a way to only > > add these extra "backup" permissions for certain unix users that are > > accessing the mount. > > > > Does that make sense? > > > > -- > > Jeff Layton <jlayton@xxxxxxxxx> > > > > Jeff, definitely. Thanks. I think one way might be to specify an > user or uid and restrict the usage of that mount to that user id? > So you can specify mount option as either backup=userxyz > or backup=1001 perhaps? > Sure, that might be reasonable. Since backup privileges are tied to a group on the server, we could also mirror that semantic on the client. Have a backup=<gid> and turn on the backup flag for any unix user who is in that group. That would seem to allow for better integration with things like nss_winbind. -- Jeff Layton <jlayton@xxxxxxxxx> -- 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
