Your message dated Fri, 24 Mar 2023 15:56:52 +0100
with message-id <8336f60d-9800-0b2e-d076-fea84aaa7...@thykier.net>
and subject line Re: Bug#1024261: debhelper: dbgsym packages contain directoryr
writable by build user
has caused the Debian Bug report #1024261,
regarding debhelper: dbgsym packages contain directory writable by build user
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1024261: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024261
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debhelper
Version: 13.10
Severity: important
util-linux dbgsym packages install /usr/lib/debug/.dwz/i386-linux-gnu/
(and other multiarch triplets) writable by an essential random uid
(= uid of the user running the build on the build system).
This was noticed by the reproducibe-builds diff check, and can be
seen here:
https://tests.reproducible-builds.org/debian/dbd/unstable/i386/util-linux_2.38.1-1.1.diffoscope.html
Example:
bsdextrautils-dbgsym_2.38.1-1.1_i386.deb
data.tar.xz file list:
-
drwxr-xr-x···0·pbuilder1··(1111)·pbuilder1··(1111)········0·2022-10-08·13:17:31.000000·./usr/lib/debug/.dwz/i386-linux-gnu/
+
drwxr-xr-x···0·pbuilder2··(2222)·pbuilder2··(2222)········0·2022-10-08·13:17:31.000000·./usr/lib/debug/.dwz/i386-linux-gnu/
Indeed, installing bsdextrautils-dbgsym_2.38.1-1.1+b1_i386.deb from the
debian-debug archive results in:
stat /usr/lib/debug/.dwz/i386-linux-gnu
File: /usr/lib/debug/.dwz/i386-linux-gnu
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 8,17 Inode: 658054 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 2952/ UNKNOWN) Gid: ( 1009/ UNKNOWN)
Access: 2022-11-16 16:04:12.991118753 +0000
Modify: 2022-11-16 16:04:06.495082135 +0000
Change: 2022-11-16 16:04:06.495082135 +0000
Birth: 2022-11-16 16:04:06.491082113 +0000
Note Uid 2952, Gid 1009.
As util-linux does not have its own code to install anything into
/usr/lib/debug, I'm assuming this is a problem in dh_dwz, but I
might be wrong. In this case, please reassign and accept my
apologies.
smcv pointed out that util-linux has Rules-Requires-Root:
binary-targets, which may be a requisite of this bug appearing.
Thanks,
Chris
--- End Message ---
--- Begin Message ---
Helmut Grohne:
Hi,
Hi Helmut
Thanks for your work - both on this specific problem and in general!
On Mon, Nov 21, 2022 at 06:08:22PM +0100, Niels Thykier wrote:
Axel Beckert:
Could this be https://bugs.debian.org/1023286 in fakeroot as well as
Niels pointed out in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024520#37 ?
It is.
So the underlying fakeroot bug has been fixed since. I don't think this
actually is a debhelper bug anymore and suggest to just close it once
the pratical effects have been mitigated.
Indeed, will do with this email.
Helmut and I discussed this on IRC and Helmut's findings is based on that
IRC discussion between him and I in relation to #1023286. (Which people not
IRC had no chance of knowing, so putting the context here for good measure)
Given that the fakeroot bug has been fixed, I have rerun the dbgsym
importer (now that no new problems can be added). Quite a number of
packages have fixed themselves since the last run. Very few were added.
I'm attaching a list of affected packages in format
"binarypackage_version_architecture". Can I ask the release team to just
binNMU all of them?
For reference, it was not clear to me that the binNMUs proposed have
been run, so I submitted a formal request to release.debian.org for the
dbgsym packages you already identified (you should get a bug report
about that soon).
I chose to use architecture-less binNMU and recommend an "ANY" binNMU to
avoid M-A:same problems. Feel free to follow up on that bug when you get
the CC from the BTS if you have any concerns in that regard.
What is a bit unclear to me is whether this is sufficient. We know
-dbgsym packages to be affected (and which), but how about regular
packages? Can they be affected as well?
In theory, yes. Though I doubt there will be many left that did not
also build a dbgsym. My guess is that we are in the 0-5 range now with
these binNMUs out the door.
If yes, we could download all .debs and record owner/group/mode for each
file after normalizing s,/${DEB_HOST_MULTIARCH}/,/, and highlight all
packages where these aspects vary accross architectures (with the
intuition that 64bit achitectures should generally be right). Does this
make sense? Does this likely encounter issues? Is this approach
exhaustive?
I think it is much more reliable and easier to check the owner / group
against the /usr/share/base-passwd/{group,passwd}.master files. For me
this:
1) Avoids having to compare a "correct" vs. a "possible faulty"
version, which reduces the amount of packages needed to be scanned.
We can limit ourselves to the 32bit architectures.
2) Avoids having to do path normalization to detect the problem.
But as mentioned above, I doubt there will many left once the dbgsym
binNMU run is complete. So any analysis done now in this space should
remove duplicates from your previous list.
In any case, binNMUing the packages from the attached list is something
actionable right now. It's just 500 packages on four architectures left.
Helmut
Once again, thanks for your work here. I passed it on to the release
managers.
Best regards,
Niels
--- End Message ---
