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