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 -- 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
