Re: Use cases for multiple uid mapping?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 28, 2020 at 8:56 AM Stéphane Graber via Containers
<containers@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Aug 28, 2020 at 11:21 AM Eric W. Biederman
> <ebiederm@xxxxxxxxxxxx> wrote:
> >
> >
> > We had a discussion in the hackroom at LPC talking about use cases for
> > a shiftfs style setup where there are different mappings of uids to
> > disk.
> >
> > In the discussion we had a couple of ideas of kernel developments
> > we should look at that address some of these.
> >
> > - Fix rlimits in user namespaces (This potentially allows multiple
> >   containers to run with the same userids simplifying the mapping
> >   problem).
> >
> > - Look at extending kuid_t to 64bits and using the highbits to
> >   implement uids that are private to user namespaces and don't
> >   map out.
> >
> > - Look at ways for allowing setgroups unprivileged.
> >
> >
> > Together this has the potential that the existing uid & gid mappings
> > will be able to function the same as the proposed fusid mappings. Fingers crossed.
> >
> >
> > I had some problems with audio and a lot of people were talking
> > quickly.  So I did not manage to capture everyone's use cases.   And I
> > definitely was not able to see how everyone's use cases interacted with
> > the changes we are looking at.
> >
> > I know for certain I missed Serge's usecase (apologies).
> >
> > Can people follow up to this and report their use cases?
> >
> > There are some real challenges and I would like to see if we
> > can solve them, while avoiding scary problems like changing
> > uids on write.
> >
> > Eric
>
> Hi Eric,
>
> It was great to have you and everyone else participate in that session.
> There was indeed a lot covered in there and a lot of use cases we'll
> have to keep in mind!
>
> The main outcomes we captured I believe were:
>  - Fixing rlimits in user namespaces such that one namespace cannot
> affect another
>  - Consider switching the kernel uid/git types to 64bit, allowing for
> a hidden 32bit identifier and fully usable 32bit uid/gid range for the
> container
Seconding this. We run into a lot of problems with high UIDs. Some
systems think that uid 2**31-1 (I think it's 2**31-1) is their version of
'nobody'. Being able to have 64-bit UIDs would solve this.

Also making sure this works with NFSv4 (both ID mapped, and non-
ID mapped) is very important to us. It's fine if the UID / GID is just
"passthrough", and we don't need different mappings between
different filesystems in NFS (for now). We would like to be able
to be able to run idmapper in the user / pid / net namespace of
the container.

>  - Find a way to allow setgroups() in a user namespace while keeping
> in mind the case of groups used for negative access control
>  - Add optional enforcement that overflow uid/gid as set through
> sysctl cannot be used as regular uid/gid on the system
>
> Christian is working on a comprehensive summary of the session based
> on the shared notes document we circulated at the beginning of the
> session which will try to separate the different topics and cover use
> cases and potential solutions for each as we discussed in the BoF.
>
> We'll make sure that everyone who attended the BoF gets CCed on that,
> on top of the usual mailing-lists so that should any of the use raised
> use cases have been missed in the notes, those folks can raise them
> again so we don't end up missing anything :)
>
> Stéphane
> _______________________________________________
> Containers mailing list
> Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
> https://lists.linuxfoundation.org/mailman/listinfo/containers
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers




[Index of Archives]     [Cgroups]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux