Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1357622

Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns

Show all headers | View raw

On Wed, Mar 9, 2016 at 6:07 PM, Seth Forshee <seth.forshee@canonical.com> wrote:
> On Wed, Mar 09, 2016 at 04:51:42PM +0100, Miklos Szeredi wrote:
>> On Wed, Mar 9, 2016 at 4:25 PM, Seth Forshee <seth.forshee@canonical.com> wrote:
>> > On Wed, Mar 09, 2016 at 03:48:22PM +0100, Miklos Szeredi wrote:
>>
>> >> 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?
>>
>> Well, actually this is what the helper does:
>>
>>     sprintf(d, "fd=%i,rootmode=%o,user_id=%u,group_id=%u",
>>         fd, rootmode, getuid(), getgid());
>
> Sorry, I was thinking of euid. So this may not be a problem.
>
>> So it just uses the current uid/gid.  Apparently no reason to do this
>> in userland, we could just as well set these in the kernel.  Except
>> for possible backward compatibility problems for things not using the
>> helper.
>>
>> BUT if the mount is unprivileged or it's a userns mount, or anything
>> previously not possible, then we are not constrained by the backward
>> compatibility issues, and can go with the saner solution.
>>
>> Does that not make sense?
>
> But we generally do want backwards compatibility, and we want userspace
> software to be able to expect the same behavior whether or not it's
> running in a user namespaced container. Obviously we can't always have
> things 100% identical, but we shouldn't break things unless we really
> need to.
>
> However it may be that this isn't actually going to break assumptions of
> existing software like I had feared. My preference is still to not
> change any userspace-visible behaviors since we never know what software
> might have made assumptions based on those behaviors. But if you're
> confident that it won't break anything I'm willing to give it a try.

I'm quite confident it won't make a difference.

Thanks,
Miklos

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside  of init_user_ns Miklos Szeredi <miklos@szeredi.hu> - 2016-03-09 12:30 +0100
  Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside  of init_user_ns Seth Forshee <seth.forshee@canonical.com> - 2016-03-09 15:20 +0100
    Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns Miklos Szeredi <miklos@szeredi.hu> - 2016-03-09 15:50 +0100
      Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside  of init_user_ns Seth Forshee <seth.forshee@canonical.com> - 2016-03-09 16:30 +0100
        Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns Miklos Szeredi <miklos@szeredi.hu> - 2016-03-09 17:00 +0100
          Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside  of init_user_ns Seth Forshee <seth.forshee@canonical.com> - 2016-03-09 18:10 +0100
            Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns Miklos Szeredi <miklos@szeredi.hu> - 2016-03-14 22:00 +0100

csiph-web