After updating sbuild recently (to version 0.88.4~bpo12+2) I started
experiencing build failures like this:

I: Unpacking /home/roberto/.cache/sbuild/unstable-amd64.tar.zst to /tmp/user/2000/tmp.sbuild.IBpZHAqVJp...
tar: /tmp/user/2000/tmp.sbuild.IBpZHAqVJp: Cannot open: Permission denied
tar: Error is not recoverable: exiting now
bad exit status (512) for tar
E: ABORT: Received PIPE signal (requesting cleanup and shutdown)

(the last line repeates several hundred or thousand times)

It would appear that sbuild now respects the setting of TMPDIR, and when
using it in an unshare configuration, the process is run under a subuid.

Regards,

- -Roberto

- -- System Information:
Debian Release: 12.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-31-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpam-tmpdir depends on:
ii  libc6           2.36-9+deb12u9
ii  libpam-runtime  1.5.2-6+deb12u1
ii  libpam0g        1.5.2-6+deb12u1

libpam-tmpdir recommends no packages.

libpam-tmpdir suggests no packages.

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAmfDgusACgkQldFmTdL1
kUI6tBAAt9NT8ei7usC/el9KrrdBLh5XBxEwA6pUVVQLiTcoAb9WicwO27JrQif9
bxVQ/8YtTLZj1RnrYhki3EQRDBp6TZoihC3cfUGjjinqHtucyiXy6BYLhevnVg+1
hijo52RiFqP+Fs9+5Xd6JIU+kB0slgh8/QGoCOAqlGJyGrrQsstAbEjrKpDayADd
Sm6rcttBovJ+1BQxZwx3AS8vpaD4gIvjRsMDU2jFZ4qE3SJkY7mMA8x5qldLKuna
Pe6FE/5L4lzBW/H7+QVxF+c6skq2V8odqmXJQrAxl7vYyL4rMdhXz6H9DHerli3A
q+jFHV0rRtGlBSsq1Yksvv57sszPtx/w3kMOQfDoAhrjWz38Oor/7MPdxc8s6IRI
CPqIsEKaN2x7mdDW0YnIhz000JbdfMRQZz72Ky29O9db5Z14XldmUNn38HVugg6q
VlnfvZjvEn1tt2QOFZkZWuCSIvGSx2ms5LLbPSBAS7eAU8gTvmVmOlYtszLGzdiF
sOuVjF5TaLSDc2SoLyZ3wjxsaj3Tvj1dq/KZdtUw598L1RgZgGemfMwqLR+kwjy4
UT7hDYC5L9Yz4y60nBpSNg9Se/EeJLYGUyl71W4uB161OSPb+V8Mga3vVvdLhfE2
/b7kOIBPZi1Ax18/hHSk3HxbLO1bZgZUA5YRcOZROqL6fpnDv8w=
=NbjM
-----END PGP SIGNATURE-----

]] "Roberto C. Sanchez"

This sounds like a bug in sbuild – it must reset the value of TMP/TMPDIR
when changing UIDs.

I'm not sure how libpam-tmpdir would discover any subuids for a given
user, do you have ideas here?

Hi Tollef,

* Tollef Fog Heen <tfheen@err.no> [2025-03-03 06:20]:

I tend to disagree here. sbuild is not changing to a different user but
to a different UID of the same user. So resetting TMPDIR would mean that
sbuild would not respect any TMPDIR and I think that would be wrong.
Instead I see two options:

1. sbuild sets acls such that subuids have access to the TMPDIR.

2. Proposed by Helumt: sbuild uses O_PATH file descriptor to pass stuff
to the user namespace.

I think both options are rather suboptimal and there are more tools
running into the same problem, like mmdebstrap in #1052471. So instead
of patching every tool to work around the specifics of libpam-tmpdir I
would prefer if libpam-tmpdir would learn about subuids.

Maybe with libsubid-dev.

I would also be fine if we just document this problem for now.

Cheers Jochen

Hi,

]] Jochen Sprickerhof

How does this work with other resources that are linked to that
particular user, whether ephemereal or not?  Say, do they share the
systemd --user instance, ssh or gpg agents?  What about $HOME, or
/run/user/$UID?  Does sbuilt open a new PAM session when switching to a
subuid?  (If not, why not?)

Is there an in-depth description of what subuids really are somewhere?
A quick search on the net did not find a design doc or explanation of
tradeoffs around the questions asked above.

Does it need to share files between different subuids?

I think it's uncovering latent bugs in software.  A bit like what
non-mainstream architectures tend to help with.

Regards,

Hi Tollef,

* Tollef Fog Heen <tfheen@err.no> [2025-05-11 21:23]:

sbuild separates the build environment from the outside system as much
as possible to make it minimal and reproducible. Specifically there is
no systemd running inside, nor does it have network or a shared
filesystems to share ssh, gpg, $HOME or /run. PAM is an interesting
question, from a quick grep sbuild does not do anything with it. Why
should it?

Maybe user_namespaces(7).

Also Helmut had some bits on it in his talk in Hamburg:

https://meetings-archive.debian.net/pub/debian-meetings/2025/MiniDebConf-Hamburg/hamburg2025-2-linux-namespaces.webm

Yes. Basically we create a new root filesystem with any number of uids,
at least a mapped root and the sbuild user and they sbuild user needs to
read the root owned files but not be able to modify it.

Cheers Jochen