Re: 32bit arch packages are built with wrong ownership due to fakeroot bug
Quoting Santiago Vila (2023-02-10 11:12:09)
> 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
Firstly, when talking about "after the first fakeroot bug was fixed", remember
that while it was fixed for i386 it was not fixed for mipsel. So all timestamps
we use in this discussion depend on the architecture we are talking about.
Secondly, this is still not about dh_fixperms so much as it is about dh_install
being called *before* the chgrp and chmod calls. You could add these calls in
other dh overrides as long as those are executed after dh_install has run. For
example you could place them into execute_before_dh_builddeb and achieve the
same effect. But yes, since the fundamental difference in these two styles of
how dh_fixperms is overridden makes the group owneership either depend on 'cp
-a' (which is broken) or on another manual chgrp (which works) you could call
it like that, I guess.
I didn't want to go into this in my last mail for similar reasons as mentioned
by smcv in their reply but since you are now explicitly asking about it: it's
true that yes, while not required, individual maintainers *could* do something
about this problem even without fakeroot being fixed: add a manual chgrp call
into their d/rules. As long as that chgrp call happens *after* dh_install
(either in execute_after_dh_fixperms or in execute_before_dh_builddeb, for
example) and *on* the files installed by dh_install, it will correct the
missing ownership information due to 'cp -a' usage in dh_install.
This will of course just paper over the issue without fixing the underlying
cause. It's what I called "not a good idea" in my last mail.
Thanks!
cheers, josch
Reply to: