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

Groups > linux.kernel > #1576488

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

From Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Newsgroups linux.kernel
Subject Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount
Date 2017-02-08 13:10 +0100
Message-ID <t8zep-a8-7@gated-at.bofh.it> (permalink)
References (8 earlier) <t8kfo-7qC-3@gated-at.bofh.it> <t8lbs-81u-7@gated-at.bofh.it> <t8mKe-q3-3@gated-at.bofh.it> <t8nGh-ZA-15@gated-at.bofh.it> <t8uop-5m1-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

On 08.02.2017 09:44, Amir Goldstein wrote:
> On Wed, Feb 8, 2017 at 1:42 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
>> On Tue, 2017-02-07 at 14:25 -0800, Christoph Hellwig wrote:
>>> On Tue, Feb 07, 2017 at 11:01:29PM +0200, Amir Goldstein wrote:
>>>> Project id's are not exactly "subtree" semantic, but inheritance
>>>> semantics,
>>>> which is not the same when non empty directories get their project
>>>> id changed.
>>>> Here is a recap:
>>>> https://lwn.net/Articles/623835/
>>>
>>> Yes - but if we abuse them for containers we could refine the
>>> semantics to simply not allow change of project ids from inside
>>> containers based on say capabilities.
>>
>
> You mean something like this:
> https://lwn.net/Articles/632917/
>
> With the suggested protected_projects, projid 0 (also inside container)
> gets a special meaning, much like user 0, so we may do interesting
> things with the projid that is mapped to 0.
>
>> We can't really abuse projectid, it's part of the user namespace
>> mapping (for project quota).  What we can do is have a new id that
>> behaves like it.
>>
>
> Perhaps we *can* use projid without abusing it.
> userns already maps projids, but there is no concept of "owning project"
> for a userns, nor does it make a lot of sense, because projid is not
> part of the credentials.
> But if we re-brand it as "container root projid", we can try to use it
> for defining semantics to grant unprivileged access to a subtree.
>
> The functionality you are trying to get with shiftfs mark does
> sounds a bit like "container root projid":
> - inodes with mapped projid MAY be uid/gid shifted
> - inodes with unmapped projid MAY NOT
>
> I realize this may be very raw, but its a start. If you like this
> direction we can try to develop it.
>
>> But like I said, we don't really need a ful ID, it would basically just
>> be a single bit mark to say remap or not when doing permission checks
>> against this inode.  It would follow some of the project id semantics
>> (like inheritance from parent dir)
>>
>
> But a single bit would only work for single level of userns nesting won't it?
>
>
>>>> I guess we should define the semantics for the required sub-tree
>>>> marking, before we can talk about solutions.
>>>
>>> Good plan.
>>
>> So I've been thinking about how to do this without subtree marking and
>> yet retain the subtree properties similar to project id.  The advantage
>> would be that if it can be done using only inode properties, then none
>> of the permission prototypes need change.  The only real subtree
>> property we need is ability to bind into an unprivileged mount
>> namespace, but we already have that.  The gotcha about marking inodes
>> is that they're all or nothing, so every subtree that gets access to
>> the inode inherits the mark.  This means that we cannot allow a user
>> access to a marked inode without the cover of an unprivileged user
>> namespace, but I think that's fixable in the permission check
>> (basically if the inode is marked you *only* get access if you have a
>> user_ns != init_user_ns and we do the permission shifts or you have
>> user_ns == init_user_ns and you are admin capable).
>>
>
> I didn't follow, but it sounds like your proposed solutions is only
> good for single level of userns nesting.
> Do you think you can redefine it in terms of "container root projid".
>

Looks like all this started from mangling uid/gid or some other metadata.
As usual, I have to propose funny/insane solutions:
proxify filesystem with fuse and mangle everything in userspace.
Or add some kind of userspace-driver remapping/mangling into overlay,
for example using BPF script (I see it everywhere nowdays).

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

Thread

Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-04 20:20 +0100
  Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Amir Goldstein <amir73il@gmail.com> - 2017-02-05 09:00 +0100
    Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-06 02:20 +0100
      Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Amir Goldstein <amir73il@gmail.com> - 2017-02-06 08:00 +0100
        Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-06 15:50 +0100
  Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount "J. R. Okajima" <hooanon05g@gmail.com> - 2017-02-06 04:30 +0100
    Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Amir Goldstein <amir73il@gmail.com> - 2017-02-06 07:40 +0100
      Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-06 17:40 +0100
    Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-06 07:50 +0100
      Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Theodore Ts'o <tytso@mit.edu> - 2017-02-06 16:00 +0100
        Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-06 16:20 +0100
          Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount lkml@pengaru.com - 2017-02-06 16:40 +0100
            Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-06 18:40 +0100
          Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount bfields@fieldses.org (J. Bruce Fields) - 2017-02-06 23:00 +0100
            Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-07 01:20 +0100
              Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount "J. Bruce Fields" <bfields@fieldses.org> - 2017-02-07 02:40 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-07 20:10 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Christoph Hellwig <hch@infradead.org> - 2017-02-07 20:50 +0100
      Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount "J. R. Okajima" <hooanon05g@gmail.com> - 2017-02-06 17:30 +0100
  Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Christoph Hellwig <hch@infradead.org> - 2017-02-07 10:20 +0100
    Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Djalal Harouni <tixxdz@gmail.com> - 2017-02-07 10:40 +0100
      Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Christoph Hellwig <hch@infradead.org> - 2017-02-07 11:00 +0100
    Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-07 17:40 +0100
      Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Amir Goldstein <amir73il@gmail.com> - 2017-02-07 19:00 +0100
        Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Christoph Hellwig <hch@infradead.org> - 2017-02-07 19:20 +0100
          Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-07 20:10 +0100
            Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Christoph Hellwig <hch@infradead.org> - 2017-02-07 21:00 +0100
              Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-07 21:10 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Amir Goldstein <amir73il@gmail.com> - 2017-02-07 22:10 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Christoph Hellwig <hch@infradead.org> - 2017-02-07 23:50 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-08 00:50 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Amir Goldstein <amir73il@gmail.com> - 2017-02-08 08:00 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Konstantin Khlebnikov <khlebnikov@yandex-team.ru> - 2017-02-08 13:10 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-08 16:00 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-08 16:30 +0100
              Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Josh Triplett <josh@joshtriplett.org> - 2017-02-08 03:00 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-08 16:30 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Josh Triplett <josh@joshtriplett.org> - 2017-02-09 11:40 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-09 17:40 +0100
                Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount ebiederm@xmission.com (Eric W. Biederman) - 2017-02-13 11:30 +0100
        Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-02-07 19:30 +0100
          Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount Djalal Harouni <tixxdz@gmail.com> - 2017-02-07 20:50 +0100

csiph-web