On Wed, Mar 09, 2016 at 03:48:22PM +0100, Miklos Szeredi wrote:

On Wed, Mar 9, 2016 at 3:18 PM, Seth Forshee [off-list ref] wrote:

quoted

On Wed, Mar 09, 2016 at 12:29:23PM +0100, Miklos Szeredi wrote:

quoted

On Mon, Jan 04, 2016 at 12:03:55PM -0600, Seth Forshee wrote:

quoted

quoted

quoted

-static int parse_fuse_opt(char *opt, struct fuse_mount_data *d, int is_bdev)
+static int parse_fuse_opt(char *opt, struct fuse_mount_data *d, int is_bdev,
+                     struct user_namespace *user_ns)
 {
    char *p;
    memset(d, 0, sizeof(struct fuse_mount_data));
    d->max_read = ~0;
    d->blksize = FUSE_DEFAULT_BLKSIZE;
+   d->user_id = make_kuid(user_ns, 0);
+   d->group_id = make_kgid(user_ns, 0);

It is true that if "user_id=" or "group_id" options were omitted we used the
zero uid/gid values.  However, this isn't actually used by anybody AFAIK, and
generalizing it for userns doesn't seem to make much sense.

So I suggest we that we instead return an error if mounting from a userns AND
neither "allow_other" nor both "user_id" and "group_id" are specified.

But those are also used for ownership of the connection files in
fusectl. In an allow_other mount shouldn't those files by owned by
namespace root and not global root?

Yes.

Can't we use current_cred()->uid/gid? Or fsuid/fsgid maybe?

That would be a departure from the current behavior in the !allow_other
case for unprivileged users. Since those mounts are done by an suid
helper all of those ids would be root in the userns, wouldn't they?

When we have true unprivileged mounts, the user_id/group_id options
become redundant anyway and we can just use the current credentials.

True, but we don't yet have that.

Thanks,
Seth

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
-- 
fuse-devel mailing list
To unsubscribe or subscribe, visit https://lists.sourceforge.net/lists/listinfo/fuse-devel