Hi Tollef, * Tollef Fog Heen <[email protected]> [2025-05-11 21:23]:
]] Jochen Sprickerhof* Tollef Fog Heen <[email protected]> [2025-03-03 06:20]:This sounds like a bug in sbuild – it must reset the value of TMP/TMPDIR when changing UIDs.I tend to disagree here. sbuild is not changing to a different user but to a different UID of the same user.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?)
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?
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.
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
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.Does it need to share files between different subuids?
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
signature.asc
Description: PGP signature
