On Tue, Aug 30, 2011 at 9:52 AM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > 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. That seems like a good idea - although I prefer that it allow uid and/or gid to be specified for easier usability -- 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
