* Accidental mountns/tmpfs API break from 2016?
@ 2026-11-03 19:58 Andy Lutomirski
2026-11-04 3:37 ` Eric W. Biederman
0 siblings, 1 reply; 5+ messages in thread
From: Andy Lutomirski @ 2026-11-03 19:58 UTC (permalink / raw)
To: Eric W. Biederman, Linux FS Devel, Linux API
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'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?
--Andy
#include <cerrno>
#include <cstdio>
#include <fcntl.h>
#include <linux/mount.h>
#include <sched.h>
#include <string>
#include <string_view>
#include <sys/syscall.h>
#include <system_error>
#include <unistd.h>
namespace {
void Check(long result, const char *operation) {
if (result < 0)
throw std::system_error(errno, std::generic_category(), operation);
}
struct OwnedFd {
int fd;
~OwnedFd() { close(fd); }
};
void WriteAll(int fd, std::string_view bytes) {
while (!bytes.empty()) {
auto n = write(fd, bytes.data(), bytes.size());
if (n < 0 && errno == EINTR)
continue;
Check(n, "write");
if (n == 0)
throw std::system_error(EIO, std::generic_category(),
"zero-length write");
bytes.remove_prefix(n);
}
}
void WriteFile(const char *path, std::string_view bytes) {
OwnedFd file{open(path, O_WRONLY | O_CLOEXEC)};
Check(file.fd, path);
WriteAll(file.fd, bytes);
}
}
int cmd_temp_shm(int argc, char **) {
if (argc != 1) {
fprintf(stderr, "Usage: lktool temp_shm\n");
return 1;
}
try {
auto uid = getuid();
auto gid = getgid();
Check(unshare(CLONE_NEWUSER | CLONE_NEWNS), "unshare user and
mount namespaces");
/*
* The outside UID and GID need to be mapped in order for the
outside tasks
* to create dentries. This comes from commit 036d523641c6
("vfs: Don't create
* inodes with a uid or gid unknown to the vfs"), which I
think may have been
* a mistake.
*/
WriteFile("/proc/self/setgroups", "deny\n");
WriteFile("/proc/self/uid_map", "0 " + std::to_string(uid) + " 1\n");
WriteFile("/proc/self/gid_map", "0 " + std::to_string(gid) + " 1\n");
OwnedFd context{static_cast<int>(syscall(SYS_fsopen, "tmpfs",
FSOPEN_CLOEXEC))};
Check(context.fd, "fsopen tmpfs");
Check(syscall(SYS_fsconfig, context.fd, FSCONFIG_CMD_CREATE,
nullptr, nullptr, 0),
"fsconfig create tmpfs");
OwnedFd mount{static_cast<int>(syscall(SYS_fsmount,
context.fd, FSMOUNT_CLOEXEC, 0))};
Check(mount.fd, "fsmount tmpfs");
Check(fchdir(mount.fd), "fchdir tmpfs");
// The detached mount is kept alive by cwd and the mount descriptor.
// No mount is attached to the inherited filesystem hierarchy.
std::string path = "/proc/" + std::to_string(getpid()) + "/cwd";
path.push_back('\0');
WriteAll(STDOUT_FILENO, path);
for (;;)
pause();
} catch (const std::system_error &e) {
fprintf(stderr, "lktool temp_shm: %s\n", e.what());
return 1;
}
}
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Accidental mountns/tmpfs API break from 2016?
2026-11-03 19:58 Accidental mountns/tmpfs API break from 2016? Andy Lutomirski
@ 2026-11-04 3:37 ` Eric W. Biederman
2026-11-04 4:02 ` Andy Lutomirski
0 siblings, 1 reply; 5+ messages in thread
From: Eric W. Biederman @ 2026-11-04 3:37 UTC (permalink / raw)
To: Andy Lutomirski; +Cc: Linux FS Devel, Linux API
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?
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?
If there is a good use case I could see it making sense to support it.
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.
We have occasionally talked about having a uid space that doesn't map to
the outside world. Perhaps by having a 64bit kuid, while uid's remain
32bit. I don't think anyone has pushed forward and merged that yet. I
did see a proposal form "cells" the other day that appeared to have a
version of that idea implemented. I mention it just in case that is
what you were expecting to exist in a fresh user namespace.
Eric
> --Andy
>
>
> #include <cerrno>
> #include <cstdio>
> #include <fcntl.h>
> #include <linux/mount.h>
> #include <sched.h>
> #include <string>
> #include <string_view>
> #include <sys/syscall.h>
> #include <system_error>
> #include <unistd.h>
>
> namespace {
> void Check(long result, const char *operation) {
> if (result < 0)
> throw std::system_error(errno, std::generic_category(), operation);
> }
>
> struct OwnedFd {
> int fd;
>
> ~OwnedFd() { close(fd); }
> };
>
> void WriteAll(int fd, std::string_view bytes) {
> while (!bytes.empty()) {
> auto n = write(fd, bytes.data(), bytes.size());
> if (n < 0 && errno == EINTR)
> continue;
> Check(n, "write");
> if (n == 0)
> throw std::system_error(EIO, std::generic_category(),
> "zero-length write");
> bytes.remove_prefix(n);
> }
> }
>
> void WriteFile(const char *path, std::string_view bytes) {
> OwnedFd file{open(path, O_WRONLY | O_CLOEXEC)};
> Check(file.fd, path);
> WriteAll(file.fd, bytes);
> }
> }
>
> int cmd_temp_shm(int argc, char **) {
> if (argc != 1) {
> fprintf(stderr, "Usage: lktool temp_shm\n");
> return 1;
> }
>
> try {
> auto uid = getuid();
> auto gid = getgid();
> Check(unshare(CLONE_NEWUSER | CLONE_NEWNS), "unshare user and
> mount namespaces");
>
> /*
> * The outside UID and GID need to be mapped in order for the
> outside tasks
> * to create dentries. This comes from commit 036d523641c6
> ("vfs: Don't create
> * inodes with a uid or gid unknown to the vfs"), which I
> think may have been
> * a mistake.
> */
> WriteFile("/proc/self/setgroups", "deny\n");
> WriteFile("/proc/self/uid_map", "0 " + std::to_string(uid) + " 1\n");
> WriteFile("/proc/self/gid_map", "0 " + std::to_string(gid) + " 1\n");
>
> OwnedFd context{static_cast<int>(syscall(SYS_fsopen, "tmpfs",
> FSOPEN_CLOEXEC))};
> Check(context.fd, "fsopen tmpfs");
> Check(syscall(SYS_fsconfig, context.fd, FSCONFIG_CMD_CREATE,
> nullptr, nullptr, 0),
> "fsconfig create tmpfs");
>
> OwnedFd mount{static_cast<int>(syscall(SYS_fsmount,
> context.fd, FSMOUNT_CLOEXEC, 0))};
> Check(mount.fd, "fsmount tmpfs");
> Check(fchdir(mount.fd), "fchdir tmpfs");
>
> // The detached mount is kept alive by cwd and the mount descriptor.
> // No mount is attached to the inherited filesystem hierarchy.
> std::string path = "/proc/" + std::to_string(getpid()) + "/cwd";
> path.push_back('\0');
> WriteAll(STDOUT_FILENO, path);
> for (;;)
> pause();
> } catch (const std::system_error &e) {
> fprintf(stderr, "lktool temp_shm: %s\n", e.what());
> return 1;
> }
> }
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Accidental mountns/tmpfs API break from 2016?
2026-11-04 3:37 ` Eric W. Biederman
@ 2026-11-04 4:02 ` Andy Lutomirski
2026-11-06 3:48 ` Eric W. Biederman
0 siblings, 1 reply; 5+ messages in thread
From: Andy Lutomirski @ 2026-11-04 4:02 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linux FS Devel, Linux API
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? :)
--Andy
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Accidental mountns/tmpfs API break from 2016?
2026-11-04 4:02 ` Andy Lutomirski
@ 2026-11-06 3:48 ` Eric W. Biederman
2026-11-09 12:05 ` Eric W. Biederman
0 siblings, 1 reply; 5+ messages in thread
From: Eric W. Biederman @ 2026-11-06 3:48 UTC (permalink / raw)
To: Andy Lutomirski; +Cc: Linux FS Devel, Linux API
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Accidental mountns/tmpfs API break from 2016?
2026-11-06 3:48 ` Eric W. Biederman
@ 2026-11-09 12:05 ` Eric W. Biederman
0 siblings, 0 replies; 5+ messages in thread
From: Eric W. Biederman @ 2026-11-09 12:05 UTC (permalink / raw)
To: Andy Lutomirski; +Cc: Linux FS Devel, Linux API
"Eric W. Biederman" <ebiederm@xmission.com> writes:
> 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:
>> 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.
This reminded me of something so I looked it up.
Then I re-read your sample code.
And I think you have asked the wrong question.
The question should be why does fsopen test may_mount? As it doesn't
mount the filesystem at that point.
Your example code could just do:
int cmd_temp_shm(int argc, char **) {
if (argc != 1) {
fprintf(stderr, "Usage: lktool temp_shm\n");
return 1;
}
try {
OwnedFd context{static_cast<int>(syscall(SYS_fsopen, "tmpfs",
FSOPEN_CLOEXEC))};
Check(context.fd, "fsopen tmpfs");
Check(syscall(SYS_fsconfig, context.fd, FSCONFIG_CMD_CREATE,
nullptr, nullptr, 0),
"fsconfig create tmpfs");
OwnedFd mount{static_cast<int>(syscall(SYS_fsmount,
context.fd, FSMOUNT_CLOEXEC, 0))};
Check(mount.fd, "fsmount tmpfs");
Check(fchdir(mount.fd), "fchdir tmpfs");
// The detached mount is kept alive by cwd and the mount descriptor.
// No mount is attached to the inherited filesystem hierarchy.
std::string path = "/proc/" + std::to_string(getpid()) + "/cwd";
path.push_back('\0');
WriteAll(STDOUT_FILENO, path);
for (;;)
pause();
} catch (const std::system_error &e) {
fprintf(stderr, "lktool temp_shm: %s\n", e.what());
return 1;
}
}
It would not surprise me if in practice there are assumptions that have
to be worked through to allow that to work, but it seems a perfectly
reasonable thing to do on first glance. Especially since there are
useful application of doing that.
The really interesting piece to make it through is FSCONFIG_CMD_CREATE.
I think that permission check and the logic there are what needs to
be modified to make it work without a user namespace.
There is also fsopen which has that has a may_mount check that seems
to serve not immediately discernible purpose.
The part that can obviously break pre-existing privileged applications
is the mount_move that attaches the mount to an existing mount
namespace, and that is obviously not allowed. That definitely can not
be allowed.
The unprivileged mounter without a usernamespace at that point won't
have the ability to reconfigure the filesystem. So the attack vectors
I was worried about earlier don't seem to apply.
There is a practical question is the additional attack surface and
maintenance burden worth it.
At a quick look it seems reasonable for a handful of filesystems like
tmpfs to allow mounting without first creating a user namespace.
There might even be an argument in there somewhere for allowing
privilege separation of the mount command.
In summary. At first glance it seems reasonable to allow fsopen,
FSCONFIG_CMD_CREATE, fsmount on select filesystems without privilege and
without a user namespace.
Eric
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-11-09 12:05 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-03 19:58 Accidental mountns/tmpfs API break from 2016? Andy Lutomirski
2026-11-04 3:37 ` Eric W. Biederman
2026-11-04 4:02 ` Andy Lutomirski
2026-11-06 3:48 ` Eric W. Biederman
2026-11-09 12:05 ` Eric W. Biederman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox