FWIW we see this in LXC containers when we use aufs to make ephemeral containers. An easy trigger seems to be deleting a file in the rw layer that exists in the ro layer.
-- You received this bug notification because you are a member of Mythbuntu Bug Team, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/729338 Title: yama hardlink restriction misbehaves under aufs Status in “linux” package in Ubuntu: Triaged Bug description: On the mythbuntu liveCD mysqld throws errors during renaming of database files because hardlink restrictions are incorrectly triggered: root@ubuntu:~# sudo -u mysql /bin/bash mysql@ubuntu:/root$ id uid=102(mysql) gid=105(mysql) groups=105(mysql) mysql@ubuntu:/root$ cd /var/lib/mysql/mysql mysql@ubuntu:/var/lib/mysql/mysql$ umask 0006 mysql@ubuntu:/var/lib/mysql/mysql$ touch cow mysql@ubuntu:/var/lib/mysql/mysql$ ls -lda . user.MYI cow drwx------ 2 mysql root 140 2011-03-04 12:44 . -rw-rw---- 1 mysql mysql 0 2011-03-04 12:44 cow -rw-rw---- 1 mysql mysql 2048 2011-03-01 19:04 user.MYI mysql@ubuntu:/var/lib/mysql/mysql$ mv cow cow2 mysql@ubuntu:/var/lib/mysql/mysql$ mv user.MYI user2 mv: cannot move `user.MYI' to `user2': Operation not permitted mysql@ubuntu:/var/lib/mysql/mysql$ dmesg | tail -n1 [ 6382.911220] non-accessible hardlink creation was attempted by: mv (fsuid 102) mysql@ubuntu:/var/lib/mysql/mysql$ cat user.MYI > cow2 mysql@ubuntu:/var/lib/mysql/mysql$ ls -la cow2 user.MYI -rw-rw---- 1 mysql mysql 2048 2011-03-04 12:45 cow2 -rw-rw---- 1 mysql mysql 2048 2011-03-01 19:04 user.MYI mysql@ubuntu:/var/lib/mysql/mysql$ lsattr cow2 user.MYI lsattr: Inappropriate ioctl for device While reading flags on cow2 lsattr: Inappropriate ioctl for device While reading flags on user.MYI mysql@ubuntu:/var/lib/mysql/mysql$ df -h . Filesystem Size Used Avail Use% Mounted on aufs 247M 28M 220M 12% / mysql@ubuntu:/var/lib/mysql/mysql$ grep aufs /proc/mounts aufs / aufs rw,noatime,si=428526c014c98973 0 0 mysql@ubuntu:/var/lib/mysql/mysql$ exit mysql@ubuntu:/var/lib/mysql/mysql# cd /sys/fs/aufs/si_428526c014c98973 root@ubuntu:/sys/fs/aufs/si_428526c014c98973# ls -la total 0 drwxr-xr-x 2 root root 0 2011-03-04 12:52 . drwxr-xr-x 3 root root 0 2011-03-04 12:52 .. -r--r--r-- 1 root root 4096 2011-03-04 12:52 br0 -r--r--r-- 1 root root 4096 2011-03-04 12:52 br1 -r--r--r-- 1 root root 4096 2011-03-04 12:52 xi_path root@ubuntu:/sys/fs/aufs/si_428526c014c98973# cat br0 /cow=rw root@ubuntu:/sys/fs/aufs/si_428526c014c98973# cat br1 /rofs=rr The main hardlink restriction check is this: if (cred->fsuid != inode->i_uid && (!S_ISREG(mode) || (mode & S_ISUID) || ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) || (generic_permission(inode, MAY_READ | MAY_WRITE, 0, NULL))) && !capable(CAP_FOWNER)) { or, in english: * Block hardlink when all of: * - fsuid does not match inode * - not CAP_FOWNER * - and at least one of: * - inode is not a regular file * - inode is setuid * - inode is setgid and group-exec * - access failure for read and write nothing visible in userspace seems to violate this, so this looks like some kind of aufs issue where the exposed inode does not match the toplevel visible to userspace? I'm not sure yet what's going on. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/729338/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~mythbuntu-bugs Post to : [email protected] Unsubscribe : https://launchpad.net/~mythbuntu-bugs More help : https://help.launchpad.net/ListHelp
