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

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

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

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

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

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)

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.

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.

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

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.

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.

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).

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).

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

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.

apport information

apport information

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

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.

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.