Hi,

During a rebuild of all packages in testing (trixie), your package failed
to build on amd64.


Relevant part (hopefully):
The full build log is available from:
http://qa-logs.debian.net/2025/04/12/munge_0.5.16-1_testing.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20250412;users=lucas@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20250412&fusertaguser=lucas@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

This is the same as bug #1094097.

The failed test output shows this error:

 > munged: Error: Logfile is insecure: invalid ownership of "/tmp"

The preconditions for that error are here:

https://sources.debian.org/src/munge/0.5.16-1/src/munged/path.c/#L224

munged is checking for that directory to be owned by either root or the
process euid, and exits immediately when that check fails.

I am unable to repro this in a unstable chroot. Is this still failing for you?

Best,
Nilesh

It is still failing.

Are you using the unshare sbuild backend?

Lucas

Yes! My .sbuildrc has

| # CHROOT_MODE
| # Type: STRING
| # Mechanism to use for chroot virtualisation.  Possible value are "schroot"
| # (default), "sudo", "autopkgtest" and "unshare".
| # See also related command line options in sbuild(1):
| #   --chroot-mode
| $chroot_mode = 'unshare';

And I can confirm from the logs that it uses the unshare chroot for build.

| Unpacking /home/nilesh/.cache/sbuild/unstable-amd64.tar.zst to /tmp/tmp.sbuild.atFNI6Qiyx...
| I: NOTICE: Log filtering will replace 'sbuild-unshare-dummy-location' with '<<CHROOT>>'
| I: NOTICE: Log filtering will replace 'build/munge-BOXUql/resolver-ECypss' with '<<RESOLVERDIR>>'

Best,
Nilesh

Hi Lucas,

* Nilesh Patra <nilesh@riseup.net> [2025-05-23 01:49]:

I can't reproduce this either. My best guess is that it depends on how
you create the chroot tarball. Can you try it with out supplying one
(sbuild will create one by itself then).

Cheers Jochen

- pre-built chroot, unshare mode, build running as user: still fails
- pre-built chroot, unshare mode, build running as root: builds fine

So its probably fine to downgrade this bug or trixie-ignore it

Lucas

Control: severity -1 important
Control: tags -1 trixie-ignore

Done.

Hi Lucas,

Do /tmp directory permissions in the chroot differ when running as a
regular user compared to root?
Best regards,

Hi Lucas,

* Lucas Nussbaum <lucas@debian.org> [2025-06-11 10:43]:

I am pretty sure that's not the real reason, at least the package builds
fine for me as a normal user. Can you write how you create the chroot or
give me access to a system to try?
Also, can you try with the automatic created chroot, as I wrote?

I am pretty sure this bug is unrelated to the package.

Cheers Jochen

I configured /tmp as a bind mount in sbuild's config, with:
$unshare_bind_mounts = [ { directory => '/tmp', mountpoint => '/tmp' } ];

that breaks munge, because it wants /tmp to be either owned by root, or
by euid.

Because of the bind mount, /tmp is owned by nobody:nobody.

Removing the bind mount makes the build pass.

Lucas

* Lucas Nussbaum <lucas@debian.org> [2025-06-12 14:51]:

We have plans to work on more options for user id mapping in forky but
nothing definite yet. Maybe we should put this example on the list.

Nice, closing accordingly.

Cheers Jochen