sudo doesn't work on unprivileged lxc container on top of ecryptfs

[Adam Ryczkowski]

On Ubuntu 14.04 64 bit, after adding a user into an unprivileged container, the sudo complains that:

$ sudo su
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

To reproduce:

1. Download and install the Ubuntu amd64 minimalcd
2. Install lxc on it and openssh for convenience.
3. follow https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ ; specifically do:
     a) sudo usermod --add-subuids 100000-165536 $USER
     b) sudo usermod --add-subgids 100000-165536 $USER
     c) sudo chmod +x $HOME
     d) create the file ~/.config/lxc/default.conf with the following contents:
lxc.include = /etc/lxc/default.conf
lxc.id_map = u 0 100000 65536
lxc.id_map = g 0 100000 65536
     e) echo "$USER veth lxcbr0 10" | sudo tee /etc/lxc/lxc-usernet
(restart is not required)
4. Create the container with
lxc-create -t download -n p1 -- -d ubuntu -r trusty -a amd64
5. Install openssh-server in the container:
lxc-start -d -n p1
lxc-attach -n p1 -- apt-get install openssh-server
6. Add a user "adam" with the group sudo
lxc-attach -n p1 -- adduser adam sudo
7. Set a password for the user
8. Log in via ssh (and provide the password from step 7)
ssh p1@adam
9. On the p1:
adam@p1$ sudo su
sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

I expected it to make change the user to root.

lxc version: 1.0.3-0ubuntu3
$cat ~/.cache/lxc/download/ubuntu/trusty/amd64/default/build_id
20141101_03:49
---
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: amd64
DistroRelease: Ubuntu 14.04
EcryptfsInUse: Yes
Package: lxc
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 3.13.0-39.66-generic 3.13.11.8
Tags: trusty
Uname: Linux 3.13.0-39-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True

[Stéphane Graber (stgraber)]

Can you paste /proc/mounts from your host please?

[Adam Ryczkowski (adam-ryczkowski)]

adam@p1:~$ cat /proc/mounts
rootfs / rootfs rw 0 0
/home/adam/.Private / ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=799bd5c1f75cea45,ecryptfs_sig=cead7dbeb43d6c20,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nodev,relatime 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /sys/fs/pstore pstore rw,relatime 0 0
udev /dev/console devtmpfs rw,relatime,size=8111212k,nr_inodes=2027803,mode=755 0 0
udev /dev/full devtmpfs rw,relatime,size=8111212k,nr_inodes=2027803,mode=755 0 0
udev /dev/null devtmpfs rw,relatime,size=8111212k,nr_inodes=2027803,mode=755 0 0
udev /dev/random devtmpfs rw,relatime,size=8111212k,nr_inodes=2027803,mode=755 0 0
udev /dev/tty devtmpfs rw,relatime,size=8111212k,nr_inodes=2027803,mode=755 0 0
udev /dev/urandom devtmpfs rw,relatime,size=8111212k,nr_inodes=2027803,mode=755 0 0
udev /dev/zero devtmpfs rw,relatime,size=8111212k,nr_inodes=2027803,mode=755 0 0
none /sys/firmware/efi/efivars efivarfs rw,relatime 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/tty1 devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/tty2 devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/tty3 devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/tty4 devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/pts devpts rw,relatime,gid=100005,mode=620,ptmxmode=666 0 0
none /sys/fs/cgroup tmpfs rw,nodev,relatime,size=4k,mode=755,uid=100000,gid=100000 0 0
none /run tmpfs rw,nosuid,nodev,noexec,relatime,size=1625360k,mode=755,uid=100000,gid=100000 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k,uid=100000,gid=100000 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime,uid=100000,gid=100000 0 0
none /run/user tmpfs rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755,uid=100000,gid=100000 0 0

[Adam Ryczkowski (adam-ryczkowski)]

Sorry, the previous one was from guest. Here is a host

adam@ubuntu-server:~$ cat /proc/mounts
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=1011476k,nr_inodes=252869,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=205004k,mode=755 0 0
/dev/dm-0 / btrfs rw,noatime,space_cache 0 0
none /sys/fs/cgroup tmpfs rw,relatime,size=4k,mode=755 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
none /run/user tmpfs rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755 0 0
none /sys/fs/pstore pstore rw,relatime 0 0
/dev/sda1 /boot ext3 rw,relatime,data=ordered 0 0
/dev/dm-0 /home btrfs rw,noatime,space_cache 0 0
systemd /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/run/cgmanager/agents/cgm-release-agent.systemd,name=systemd 0 0
/home/zosia/.Private /home/zosia ecryptfs rw,nosuid,nodev,relatime,ecryptfs_fnek_sig=e9a5867908bf1b34,ecryptfs_sig=65ba6ff1cded08ed,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0

[Serge Hallyn (serge-hallyn)]

Thanks for reporting this bug.

Exactly which minimalcd did you use?

Which kernel version is the host running ('uname -r')?

Which filesystem is the host's $HOME on?

 status: incomplete

[Adam Ryczkowski (adam-ryczkowski)]

I really don't know how to tell you, which Trusty's 64bit minimal cd I used. I didn't even know that there are more than one.

I just downloaded the fresh minimal cd about week before posting this bug. When opening the minimal cd in file browser I see no files with names "version", "changelog" or anything similar. The best I found a contents of the .disk/mini-info:

Ubuntu 14.04 "trusty" - amd64 (20101020ubuntu318)

uname -r
3.13.0-39-generic

Host's home lies on ecryptfs on top of btrfs:

$ mount
/dev/mapper/sdalvm-root on / type btrfs (rw,noatime,subvol=@)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
/dev/mapper/sdalvm-root on /home type btrfs (rw,noatime,subvol=@home)
/dev/sda1 on /boot type ext3 (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
/home/zosia/.Private on /home/zosia type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=65ba6ff1cded08ed,ecryptfs_fnek_sig=e9a5867908bf1b34)

[Serge Hallyn (serge-hallyn)]

Quoting Adam Ryczkowski (<email address hidden>):
> I really don't know how to tell you, which Trusty's 64bit minimal cd I

The full url.

[Serge Hallyn (serge-hallyn)]

Ah, the ecryptfs $HOME might be the problem. I haven't tested that
and wouldn't be surprised if ecryptfs prevented the console from
looking ok. Could you try something like:

rm -rf $HOME/.config/lxc $HOME/.local/share/lxc
sudo mkdir /opt/lxc
sudo chown -R $USER /opt/lxc
mkdir /opt/lxc/config /opt/lxc/store
ln -s /opt/lxc/store $HOME/.local/share/lxc
ln -s /opt/lxc/config $HOME/.config/lxc

Then re-try the container create/setup. This will create the
container rootfs on a non-ecryptfs filesystem.

[Adam Ryczkowski (adam-ryczkowski)]

On 19.11.2014 15:35, Serge Hallyn wrote:
> Ah, the ecryptfs $HOME might be the problem. I haven't tested that
> and wouldn't be surprised if ecryptfs prevented the console from
> looking ok. Could you try something like:
>
> rm -rf $HOME/.config/lxc $HOME/.local/share/lxc
> sudo mkdir /opt/lxc
> sudo chown -R $USER /opt/lxc
> mkdir /opt/lxc/config /opt/lxc/store
> ln -s /opt/lxc/store $HOME/.local/share/lxc
> ln -s /opt/lxc/config $HOME/.config/lxc
>
> Then re-try the container create/setup. This will create the
> container rootfs on a non-ecryptfs filesystem.
>
Yes! That resolved the problem. Thank you!

Would you be able to tell me, why ecryptfs pose a problem for a sudo in
a container?

Adam

[Serge Hallyn (serge-hallyn)]

Great, thanks for the information.

ecryptfs is a stackable filesystem, meaning that it sits between a real filesystem and your view of it, interpreting (encrypting/decrypting) data. There are several things which are notably difficult for a stackign filesystem to get right.

I'm going to mark this bug as affecting ecryptfs mainly so others can find the information should they run into this. However it is not something I would actually expect to get fixed, though it's not impossible.

[Adam Ryczkowski (adam-ryczkowski)]

For one thing, the lxc-create can check if it is going to create a
user-space container on top of the ecryptfs, and warn the user if
appriopriate with the link to this bug report. That should be fairly
easy to implement, because on the default setup the ecryptfs would be
the underlying fs, so there is no need to dig into the nested mounts.

[Adam Ryczkowski (adam-ryczkowski)]

For one thing the lxc-create could warn the user (with the link to this
bug report) if it finds, that the user is attempting to create a
user-space container on top of the ecryptfs. I believe that should be
fairly easy to implement. And I guess it is rather important to do,
because user never gets a warning about the inherent incompatiblity
between user-space containers and encrypted home folder (which is
featured by the Ubuntu installer).

[Serge Hallyn (serge-hallyn)]

Quoting Adam Ryczkowski (<email address hidden>):
> For one thing, the lxc-create can check if it is going to create a
> user-space container on top of the ecryptfs, and warn the user if

True. Though I would prefer not to work around the bug like this
until we are certain that it cannot be made to work (by fixing
ecryptfs in the kernel).

[Serge Hallyn (serge-hallyn)]

(marking low priority for lxc because ther eis a workaround)

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1389305

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Adam Ryczkowski (adam-ryczkowski)]

apport information

[Adam Ryczkowski (adam-ryczkowski)]

apport information

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jean-Pierre van Riel (jpvr)]

It also affected me on Ubuntu 16.04 LTS with /var/lib/lxc mount via bind.

My original setup only had 8GB for /var, so a bind to directory in /home was the custom hack I did to give lxc more space.

$ grep lxc /etc/fstab
/home/var/lib/lxc /var/lib/lxc none bind 0 0

Once tested without the bind, the error was gone.

[Jean-Pierre van Riel (jpvr)]

Update on the previous comment, I realised the issue was the the partition where /var was mounted to hat nosuid set. Seems /var/lib/lxc must allow for the suid bit to be set. The problem is that people often have /home mounted with nosuid as a normal security precaution, so this effects running unprivileged containers as well.