On Mon, 19 Sep 2011 13:34:35 -0500 Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > On Sun, Sep 18, 2011 at 7:00 AM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > > On Sat, 17 Sep 2011 14:04:56 -0500 > > Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > > > >> 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). > >> > > > > There most certainly is a way to check this in the kernel. It has to do > > this all the time to check permissions. See in_group_p(). > > > > You don't want to check whether the current uid is in a particular > > group, but rather whether the current task credential is. Otherwise > > that code won't work if someone runs this under newgrp and the group is > > password protected. > > > > -- > > Jeff Layton <jlayton@xxxxxxxxx> > > > > So a check should be whether the gid specified with the > mount option backupgid is either same as egid of the task > or one of the gids of the supplementary groups to which > euid of the task belongs to! > Right -- that's what in_group_p() does. > Not sure how the acquired egid using newgroup api/command > and password protection comes into the picture in this context. > If you just call in_group_p then you shouldn't need to do anything else. -- 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
