Thinking more about it, this might be due to the lack of
CAP_DAC_OVERRIDE so I guess I need this too right?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1659087
Title:
open(2) returns EOVERFLOW wit
Trying the fsuid/fsgid workaround, I came across another oddity:
$ id -u
1000
$ id -g
1000
$ unshare -r -U -m /bin/bash
# mount -t tmpfs tmpfs /mnt
# chmod 555 /mnt
# ls -ldn /mnt
dr-xr-xr-x 2 0 0 40 Jan 26 14:15 /mnt
# echo $$
2354
In another terminal:
$ sudo nsenter -G 1000 -S 1000 -t 2354 -m
Glad you figured it out, I suspected this had something to do with the
may_create/may_o_create code paths but couldn't wrap my head around it.
Hopefully this will be addressed upstream in the near future.
This change in behavior is surprising though, maybe this should be
documented in user_namespa
I can't reproduce the issue on Fedora 4.9.5-200.fc25.x86_64 either.
As you pointed out, setting the fsuid/fsgid to a known userns mapping does work.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/165908
Interesting, I tried to reproduce with a Debian strech 4.8.0-2-amd64
(Debian 4.8.15-2) and 4.9.0-1-amd64 (Debian 4.9.2-2) and didn't hit the
error.
This seems to be specific to tmpfs though, touching the file anywhere
else yields the nobody:nogroup mapping.
Regarding my use-case, I'm creating the
Public bug reported:
On Ubuntu 4.4.0-59.80-generic 4.4.35, open(2) returns EOVERFLOW when
creating a file in tmpfs with user namespace enabled.
This issue wasn't present in 4.4.0-47 and has probably been introduced
by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1634964
Step to reproduce
