Re: Accidental mountns/tmpfs API break from 2016?

["Eric W. Biederman" <ebiederm@xmission.com>]

Andy Lutomirski <luto@amacapital.net> writes:

 On Tue, Nov 3, 2026 at 7:37 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
>>
>> Andy Lutomirski <luto@amacapital.net> writes:
>>
>> > Hi-
>> >
>> > I (well, an LLM following my rather explicit instructions) just wrote
>> > a little tool to make a tmpfs as an unprivileged user: it unshares
>> > userns and mountns, makes a tmpfs, fchdirs to it, and prints
>> > /proc/PID/cwd to stdout.  Full source below.
>> >
>> > I was a bit surprised that trying to create anything in the tmpfs did
>> > not work without a uid_map and gid_map.  It looks like it came from:
>> >
>> > commit 036d523641c66bef713042894a17f4335f199e49
>> > Author: Eric W. Biederman <ebiederm@xmission.com>
>> > Date:   Fri Jul 1 12:52:06 2016 -0500
>> >
>> >     vfs: Don't create inodes with a uid or gid unknown to the vfs
>> >
>> >     It is expected that filesystems can not represent uids and gids from
>> >     outside of their user namespace.  Keep things simple by not even
>> >     trying to create filesystem nodes with non-sense uids and gids.
>> >
>> >     Acked-by: Seth Forshee <seth.forshee@canonical.com>
>> >     Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>> >
>> >
>> > Now my tool won't actually run on a pre-2016 kernel due to use of
>> > fsopen, and I'm not about to say that a decade-old commit broke my ABI
>> > and needs to be reverted.  But I am rather curious whether this rule
>> > actually makes sense.
>>
>> I am pretty certain it was deliberate at the time.
>>
>> > I'm not creating an idmapped mount, and I'm
>> > using tmpfs, which could not care less about the mapping as far as I
>> > know.
>> >
>> > Would it make sense to only enforce this for filesystems that care?
>>
>> Interesting question.  You are in a user namespace.  You are
>> running as a user that does not exist in your user namespace.
>> You want to create files.
>>
>> You can map a that single uid and gid without privileges.
>> So there is no hardship in getting a uid and gid in your user namespace.
>>
>> Is it just the extra bit of code to perform that write that is the
>> problem?
>>
>> Why would you want to be able to create files as a owned by a user
>> from another user namespace?  Even if you created them reading them
>> would show an 0xfffe the invalid uid/gid.  I think there are then
>> some difficulties in using those files as well.
>>
>> Why would you want to do much of anything as without having a
>> properly setup uid or gid?
>
> Hah, you haven't quite figured out the ridiculous thing I'm doing. :)
> What I want is a temporary tmpfs that I can create as an unprivileged
> user.  Linux doesn't let me do that directly, so I'm kludging it.
> Shell transcript, edited for clarity:
>
> #### Make a tmpfs, keeping the tool running to keep it alive
> $ ./temp_shm &
> [1] 34157
> /proc/34157/cwd
>
> #### cd to the tmpfs, which references it and keeps it alive
> $ cd /proc/34157/cwd
>
> #### Kill the tool, since we're done with it
> $ fg
> bin/lktool temp_shm     (wd: /workspaces/master)
> ^C
>
> #### cwd is a working tmpfs!
> $ echo "Look a tmpfs!" >some_file
>
> #### and it has no '..', as expected :)
> $ cd ..                  # and it has
> cd: error retrieving current directory: getcwd: cannot access parent
> directories: No such file or directory
>
> This whole workflow runs in the init userns and the init mountns,
> which is exactly what I wanted.  And now I have a tmpfs that I can use
> to run my test suite unprivileged to test some cool code that *needs*
> a tmpfs.  (Yes, I could probably use /dev/shm, but that's messy and I
> don't want to.)
>
> I'm not actually banging this out in shell, but I am running literally
> the C++ code I posted as a subprocess called by my test harness.
>
> The user creating files is not in the mountns or the userns, by design.
>
>>
>> At a quick look tmpfs just uses vfs inodes which use kuid_t and kgid_t
>> so it theoretically would be ok.
>>
>> Still what would be the motivation for supporting something so silly?
>>
>
> My test suite! :)
>
>> If there is a good use case I could see it making sense to support it.
>
> I think my use case is excellent.
>
> Seriously, though, I think a *much* nicer solution would be to allow
> fsconfig and fsmount to be called by an unprivileged user, at least
> for some very limited list of filesystems.
>
>>
>> Short of a good use case we are talking about having to support weird
>> corner cases that no one really cares about that will just bit-rot.
>>
>> Note.  You can identity map your original uid and gid, instead of
>> mapping your uid and gid 0.
>
> Does the inner uid made a sound if there's no running task to observe
> it? :)

Hmm.  So the problem is that the user outside of the user namespace
can't write files unless he is mapped.

I think I even remember why that happened originally, it seems very
familiar.

I think that was to prevent processes running inside of a user namespace
from having to deal with files and directories appearing on their
filesystem that their isn't full information for because they aren't
mapped.

In particular I think it prevents "chmod u+S file" on a file that isn't
mapped into the user namespace.

The issue is that the mounter of the filesystem has all caps over the
filesystem.

So in general you don't want them to be able to manipulate files that
they couldn't create.

Eric