mythbuntu-bugs team mailing list archive
-
mythbuntu-bugs team
-
Mailing list archive
-
Message #05844
[Bug 729338] Re: yama hardlink restriction misbehaves under aufs
Same problem here. Use this script to reproduce
----script:
testuser=set-a-valid-non-root-user
mkdir d1/
mkdir d1/x/
echo "This is a samefile-test" >d1/x/file.txt
chown $testuser: d1/x/ d1/x/*
mksquashfs d1/ testdata_L1.squashfs -noappend
mkdir L1root
mount -t squashfs -oloop ./testdata_L1.squashfs L1root/
mkdir L2top
mkdir aufs
mount -t aufs -odirs=L2top=rw:L1root=ro,sum none aufs/
su $testuser -c "rm --interactive=none /tmp/aufstest/aufs/x/file.txt" ; echo $?
dmesg | tail
----find L*/ aufs/ -ls after mounting
2 0 drwxr-xr-x 3 root root 24 Okt 12 23:44 L1root/
1 0 drwxr-xr-x 2 daniel daniel 31 Okt 12 23:44 L1root/x
3 1 -rw-r--r-- 1 daniel daniel 24 Okt 12 23:44 L1root/x/file.txt
696501 4 drwxr-xr-x 4 root root 4096 Okt 12 23:44 L2top/
696504 4 drwx------ 2 root root 4096 Okt 12 23:44 L2top/.wh..wh.orph
696503 4 drwx------ 2 root root 4096 Okt 12 23:44 L2top/.wh..wh.plnk
656502 0 -r--r--r-- 1 root root 0 Okt 12 23:44 L2top/.wh..wh.aufs
2 4 drwxr-xr-x 5 root root 4096 Okt 12 23:44 aufs/
12 0 drwxr-xr-x 2 daniel daniel 31 Okt 12 23:44 aufs/x
13 1 -rw-r--r-- 1 daniel daniel 24 Okt 12 23:44 aufs/x/file.txt
----
using both self-compiled aufs 2.2-standalone.tree-38-20110919 and
default aufs.ko from 2.6.38-11-generic (natty)
--
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