El 10/2/23 a las 3:18, Johannes Schauer Marin Rodrigues escribió:
I do not understand what makes you think that only packages using dh_fixperms
-X are affected? I think what makes the two packages that I found fail to have
correct permissions is that they both use dh_install which in turn uses 'cp -a'
which is broken under fakeroot on our 32bit architectures right now. I patched
mutt and added an 'ls -lha' in execute_before_dh_builddeb to show the problem:
$ ls -lha debian/tmp/usr/bin/mutt_dotlock debian/mutt/usr/bin/mutt_dotlock
-rwxr-sr-x 1 root root 9.6K Feb 9 22:06 debian/mutt/usr/bin/mutt_dotlock
-rwxr-sr-x 1 root mail 28K Feb 9 22:05 debian/tmp/usr/bin/mutt_dotlock
So the chgrp call in Makefile.am worked correctly and set the group owner to
"mail" but after dh_install moved mutt_dotlock from debian/tmp/ to debian/mutt/
using 'cp -a' (if I'm reading the code correctly) the group ownership
information is lost.
I mean: There are mainly two ways to ship files not root:root inside a package.
One way is to accept the special permissions/ownerships resulting from
dh_install
and then avoid resetting them in dh_fixperms using -X or --exclude.
This is from mutt's debian/rules:
override_dh_fixperms:
dh_fixperms --exclude usr/bin/mutt_dotlock
The other way is not to care about the permissions from dh_install and set them
after dh_fixperms no matter what. This is from procmail's debian/rules:
override_dh_fixperms:
dh_fixperms
chgrp mail debian/procmail/usr/bin/procmail
chgrp mail debian/procmail/usr/bin/lockfile
chmod 6755 debian/procmail/usr/bin/procmail
chmod 2755 debian/procmail/usr/bin/lockfile
The minor observation is that packages which set permissions in the second
way which were uploaded after the first fakeroot bug was fixed seem
not to be affected:
dpkg -c procmail_3.24-1_i386.deb | grep -v root/root
-rwxr-sr-x root/mail 26292 2023-01-05 22:35 ./usr/bin/lockfile
-rwsr-sr-x root/mail 112668 2023-01-05 22:35 ./usr/bin/procmail
Thanks.
