On Fri, Jan 29, 2021 at 05:11:53PM -0600, Eric W. Biederman wrote:
> "Serge E. Hallyn" <serge@xxxxxxxxxx> writes:
>
> > On Thu, Jan 28, 2021 at 08:44:26PM +0100, Miklos Szeredi wrote:
> >> On Thu, Jan 28, 2021 at 6:09 PM Serge E. Hallyn <serge@xxxxxxxxxx> wrote:
> >> >
> >> > On Tue, Jan 19, 2021 at 07:34:49PM -0600, Eric W. Biederman wrote:
> >> > > Miklos Szeredi <mszeredi@xxxxxxxxxx> writes:
> >> > >
> >> > > > if (!rootid_owns_currentns(kroot)) {
> >> > > > - kfree(tmpbuf);
> >> > > > - return -EOPNOTSUPP;
> >> > > > + size = -EOVERFLOW;
> >> >
> >> > Why this change? Christian (cc:d) noticed that this is a user visible change.
> >> > Without this change, if you are in a userns which has different rootid, the
> >> > EOVERFLOW tells vfs_getxattr to vall back to __vfs_getxattr() and so you can
> >> > see the v3 capability with its rootid.
> >> >
> >> > With this change, you instead just get EOVERFLOW.
> >>
> >> Why would the user want to see nonsense (in its own userns) rootid and
> >> what would it do with it?
> >
> > They would know that the data is there.
>
> But an error of -EOVERFLOW still indicates data is there.
> You just don't get the data because it can not be represented.
Ok - and this happens *after* the check for whether the rootid to maps
into the current ns.
That sounds reasonable, thanks.
> >> Please give an example where an untranslatable rootid would make any
> >> sense at all to the user.
> >
> > I may have accidentally, from init_user_ns, as uid 1000, set an
> > fscap with rootid 100001 instead of 100000, and wonder why the
> > cap is not working in the container where 100000 is root.
>
> Getting -EOVERFLOW when attempting to read the cap from inside
> the user namespace will immediately tell you what is wrong. The rootid
> does not map.
>
> That is how all the non-mapping situations are handled. Either
> -EOVERFLOW or returning INVALID_UID/the unmapped user id aka nobody.
>
> The existing code is wrong because it returns a completely untranslated
> uid, which is completely non-sense.
>
> An argument could be made for returning a rootid of 0xffffffff aka
> INVALID_UID in a v3 cap xattr when the rootid can not be mapped. I
> think that is what we do with posix_acls that contain ids that don't
> map. My sense is returning -EOVERFLOW inside the container and
> returning the v3 cap xattr outside the container will most quickly get
> the problem diagnosed, and will be the most likely to not cause
> problems.
>
> If there is a good case for returning a v3 cap with rootid of 0xffffffff
> instead of -EOVERFLOW we can do that. Right now I don't see anything
> that would be compelling in either direction.
>
> Eric
>
>
>
