Hmm. In this case it's really the kernel that is writing the xattr, so in that case #2 kind of makes sense. It's also more than a bit scary, assigning CAP_SYS_ADMIN in init_user_ns to a task from a user namespace. Now we're already doing it for unprivileged users in init_user_ns which isn't all that different, except for the fact that in the user namespace that unprivileged user can also create the overlay mount, and that leaves me feeling a bit uneasy. I'm not familiar enough with overlayfs to decide whether or not this really presents an opportunity for someone to do something malicious to the lower fs.
With #1, I don't think we have a way to distinguish between overlayfs trying to write this xattr and userspace writing it directly, do we? This also might present an opportunity for a user to do something mildly malicious. I can't comment on #3, I just don't know enough about overlayfs. I don't really any other ideas. #2 seems the most logical to me if we can be sure that it's safe. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1531747 Title: overlay: mkdir fails if directory exists in lowerdir in a user namespace Status in linux package in Ubuntu: Triaged Status in linux source package in Wily: Triaged Status in linux source package in Xenial: Triaged Bug description: If a directory exists in the lowerdir but not in the mounted overlay, then mkdir of the directory in the target dir results in a mysterious -EPERM. I've seen this both in wily kernel (4.2.0-22-generic #27-Ubuntu) and in a hand-built xenial master-next (with unrelated patches added). ===================================================== #!/bin/sh -ex dir=`mktemp -d` cleanup() { umount -l $dir/t rm -rf $dir } trap cleanup EXIT echo "dir is $dir" mkdir -p $dir/l $dir/u $dir/w $dir/t mkdir $dir/l/dev mount -t overlay -o lowerdir=$dir/l,upperdir=$dir/u,workdir=$dir/w o $dir/t stat $dir/t/dev rmdir $dir/t/dev mkdir $dir/t/dev echo $? echo "mkdir should have succeeded" ===================================================== The above will work on the host, but fail in a user namespace, i.e in a regular lxd container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1531747/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp