[arch-dev-public] critical: fakeroot broken again, breaks makepkg
Oops, this should have gone to the public list directly, so I'll repost it here:
I saw this problem a while ago already, but didn't really investigate it. When building a package, you would often end up with non-world-readable /usr/man/manX directories.
This happens whenever this code in makepkg is executed:
# move /usr/share/man files to /usr/man if [ -d $startdir/pkg/usr/share/man ]; then cd "$startdir" mkdir -p pkg/usr/man cp -a pkg/usr/share/man/* pkg/usr/man/ rm -rf pkg/usr/share/man fi
This can be reproduced easily:
[09:29:39][thomas@artin shm]$ fakeroot bash-3.2# mkdir -p foo/ab bar bash-3.2# ls -al foo/ bar/ bar/: total 0 drwxr-xr-x 2 root root 40 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 ..
foo/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwxr-xr-x 2 root root 40 Jul 12 09:29 ab bash-3.2# cp -a foo/* bar/ bash-3.2# ls -al foo/ bar/ bar/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwx------ 2 root root 40 Jul 12 09:29 ab
foo/: total 0 drwxr-xr-x 3 root root 60 Jul 12 09:29 . drwxrwxrwt 4 root root 100 Jul 12 09:29 .. drwxr-xr-x 2 root root 40 Jul 12 09:29 ab bash-3.2#
I can't find out exactly what's causing this, so if anyone has an idea, feel free to share it. This should definitely be fixed quickly, as it prevents me from updating several packages.
Thomas Bächler wrote:
Andrew Fyfe schrieb:
Looking at your example I'm assuming you ran it in /dev/shm?
I did. But I was able to reproduce it on a "normal" ext3, which is however mounted with "acl,user_xattr". On an ext3 mounted without those options, it works.
I've just tried the same test on my ubuntu box (glibc-2.6, coreutils-5.97, fakeroot-1.7.1) and all is OK, so my guess at the moment is this is a coreutils issue.
It is a fakeroot issue. Coreutils seems to have introduced yet another change that isn't caught by fakeroot properly.
This problem only happens on tmpfs or a filesystem mounted with the acl option, and it only effects directories.
When running on a working fs it copies the directory and chmods it 0700, then it chmods it with it's correct permissions. When running on a tmpfs or an fs with acl it doesn't do the second chmod.
Not sure where to go from here, I'm a noob when it comes to C :)
Andrew
fakeroot debug:
/tmp (reiserfs without acl) --------------------------- FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(306:8886), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(306:8886), mode=040755, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(306:8885), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(306:8885), mode=040755, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=1 FAKEROOT: chmod, mode=40700 FAKEROOT: insert_or_overwrite unknown stat: dev:ino=(306:8890), mode=040700, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(306:8890), mode=040700, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(306:8890), mode=040700, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=0 FAKEROOT: chown dev:ino=(306:8890), mode=040700, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=1 FAKEROOT: chmod, mode=40755
/mnt (ext3 with acl) -------------------- FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(308:31297), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(308:31297), mode=040755, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(308:15650), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(308:15650), mode=040755, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=1 FAKEROOT: chmod, mode=40700 FAKEROOT: insert_or_overwrite unknown stat: dev:ino=(308:31298), mode=040700, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(308:31298), mode=040700, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(308:31298), mode=040700, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=0 FAKEROOT: chown dev:ino=(308:31298), mode=040700, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(308:15650), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(308:15650), mode=040755, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(308:15650), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(308:15650), mode=040755, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(308:31298), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(308:31298), mode=040700, own=(0,0), nlink=2, rdev=0
/dev/shm (tmpfs) ---------------- FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(e:13507), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(e:13507), mode=040755, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(e:13506), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(e:13506), mode=040755, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=1 FAKEROOT: chmod, mode=40700 FAKEROOT: insert_or_overwrite unknown stat: dev:ino=(e:13509), mode=040700, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(e:13509), mode=040700, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(e:13509), mode=040700, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=0 FAKEROOT: chown dev:ino=(e:13509), mode=040700, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(e:13506), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(e:13506), mode=040755, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(e:13506), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(e:13506), mode=040755, own=(0,0), nlink=2, rdev=0 FAKEROOT: r=56, received message type=1, message=3 FAKEROOT: process stat oldstate=dev:ino=(e:13509), mode=040755, own=(1000,101), nlink=2, rdev=0 FAKEROOT: (previously known): fake=dev:ino=(e:13509), mode=040700, own=(0,0), nlink=2, rdev=0
Andrew Fyfe wrote:
Thomas Bächler wrote:
Andrew Fyfe schrieb:
Looking at your example I'm assuming you ran it in /dev/shm?
I did. But I was able to reproduce it on a "normal" ext3, which is however mounted with "acl,user_xattr". On an ext3 mounted without those options, it works.
I've just tried the same test on my ubuntu box (glibc-2.6, coreutils-5.97, fakeroot-1.7.1) and all is OK, so my guess at the moment is this is a coreutils issue.
It is a fakeroot issue. Coreutils seems to have introduced yet another change that isn't caught by fakeroot properly.
This problem only happens on tmpfs or a filesystem mounted with the acl option, and it only effects directories.
When running on a working fs it copies the directory and chmods it 0700, then it chmods it with it's correct permissions. When running on a tmpfs or an fs with acl it doesn't do the second chmod.
Not sure where to go from here, I'm a noob when it comes to C :)
Andrew
A little more digging...
It looks like coreutils uses acl to set the permissions on a directory when using 'cp -a' [1] and as fakeroot doesn't wrap acl functions the permissions aren't being carried across.
Andrew
[1] http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/acl.c;h=84c595ab24d1...
Andrew Fyfe wrote:
Andrew Fyfe wrote:
Thomas Bächler wrote:
Andrew Fyfe schrieb:
Looking at your example I'm assuming you ran it in /dev/shm?
I did. But I was able to reproduce it on a "normal" ext3, which is however mounted with "acl,user_xattr". On an ext3 mounted without those options, it works.
I've just tried the same test on my ubuntu box (glibc-2.6, coreutils-5.97, fakeroot-1.7.1) and all is OK, so my guess at the moment is this is a coreutils issue.
It is a fakeroot issue. Coreutils seems to have introduced yet another change that isn't caught by fakeroot properly.
This problem only happens on tmpfs or a filesystem mounted with the acl option, and it only effects directories.
When running on a working fs it copies the directory and chmods it 0700, then it chmods it with it's correct permissions. When running on a tmpfs or an fs with acl it doesn't do the second chmod.
Not sure where to go from here, I'm a noob when it comes to C :)
Andrew
A little more digging...
It looks like coreutils uses acl to set the permissions on a directory when using 'cp -a' [1] and as fakeroot doesn't wrap acl functions the permissions aren't being carried across.
Andrew
[1] http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/acl.c;h=84c595ab24d1...
arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
The relevant code from cp... [1]http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/copy.c;h=b7bf73b8... [2]http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/copy.c;h=b7bf73b8... [3]http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/copy.c;h=b7bf73b8...
Andrew
Andrew Fyfe schrieb:
A little more digging...
It looks like coreutils uses acl to set the permissions on a directory when using 'cp -a' [1] and as fakeroot doesn't wrap acl functions the permissions aren't being carried across.
Bad, all my data (and thus build) partitions are mounted with the acl option. Isn't there a fix for fakeroot somewhere?
On 7/12/07, Thomas Bächler thomas@archlinux.org wrote:
Andrew Fyfe schrieb:
A little more digging...
It looks like coreutils uses acl to set the permissions on a directory when using 'cp -a' [1] and as fakeroot doesn't wrap acl functions the permissions aren't being carried across.
Bad, all my data (and thus build) partitions are mounted with the acl option. Isn't there a fix for fakeroot somewhere?
On 7/12/07, Dan McGee dpmcgee@gmail.com wrote:
Bad, all my data (and thus build) partitions are mounted with the acl option. Isn't there a fix for fakeroot somewhere?
Thomas poked me today, letting me know this is still an issue.
If I'm reading this correctly, it is ONLY with a FS mounted with acl support, or a tmpfs filesystem
Lets revisit this, guys, it's pretty critical.
Any ideas / thoughts?
participants (4)
-
Aaron Griffin
-
Andrew Fyfe
-
Dan McGee
-
Thomas Bächler