On Tue, Aug 30, 2011 at 12:54 PM, Steve French <smfrench@xxxxxxxxx> wrote: > On Tue, Aug 30, 2011 at 12:32 PM, Shirish Pargaonkar > <shirishpargaonkar@xxxxxxxxx> wrote: >> On Tue, Aug 30, 2011 at 12:09 PM, Steve French <smfrench@xxxxxxxxx> wrote: >>> 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 >>> >> >> Steve, how would we be able to distinguish between uids and gids? >> The same id e.g 1001, could be either an uid or a gid! >> The same applies to a name, it could be a group as well as >> an user name. > One option - allow them to distinguished via different mount option: > > presumably "backupuid=" and "backupgid=" If we choose to retain > "backup" as a mount option as well - then when neither backupuid nor > backupgid is specified then the uid of the process mounting would be > used as "backupuid" with no backupgid implied by default. > > > > -- > Thanks, > > Steve > Not sure if there is a way to check in kernel whether a user/uid is part of a certain group/gid! If not, I think the options are to do so by perhaps making a upcall or verify whether the specified group/gid is the primary group of the user/uid accessing the file (in the backup intent mode) on the server. My preference is for the second option and we can clarify this in the man page stanza of this mount option (backupgid). Regards, Shirish -- 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
