1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1099301: libpam-tmpdir: please set TMPDIR ACLs for compatibility wi

    From Tollef Fog Heen@21:1/5 to tradeoffs around the questions on Sun May 11 21:30:01 2025
    Hi,

    ]] Jochen Sprickerhof

    * Tollef Fog Heen <tfheen@err.no> [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?)

    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.

    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?

    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.

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

    Regards,
    --
    Tollef Fog Heen
    UNIX is user friendly, it's just picky about who its friends are

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jochen Sprickerhof@21:1/5 to All on Sun May 11 22:10:01 2025
    Hi Tollef,

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

    * Tollef Fog Heen <tfheen@err.no> [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

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEc7KZy9TurdzAF+h6W//cwljmlDMFAmghAogACgkQW//cwljm lDPJkQ//TobAtAskjoxx24NgyjOY4pWKv6X0alSkxXCIZ2yiYXnW1zub4CN/5iBk IJAt+Cs3kklv22ZNmvvNNji2FxYVgyOdlZ2vECdor35WYwD4ufsPzKIUsSag0BF3 z1AeH9WLr0uqOdIDJ4mls5Fdx2rpXhF/vpoQNMdsyyPZV0omPRSjFPDuESFt+0Dj 5SSXkZaT+ciJcdKqnTL6wqgVkF5oT8zwJHHkH0rKWPV2pUT4wJD8yxrr7LocE9TZ ttx3VQN7OL3dN+DurVihtVDB/v75FlEw15JWlms5/9rydQHIRsrFTXD4KlVOsgVp +mhF2QHzc6exVHhe/xmu5S+Vy8uN+qJi+XtHSXACs8+UVo3+6k1ugrclVDHk6LwG G1BAOzBnUQtoMrUzniA7OnBmvsnnf4K3y/xNsfy5K8GrAOIlaAohPvGrbxJ/KNtC wn0gk1ZnHMNcqYq0Y8XUbbEGgXWcvCiAI8VR3H3HwuzUrEHQsxF9E4GJaxgG77BP V+vrBiQ4sxjrz5JMvvLSYyrdByOm0Tqbsudod7av1/EqptuIKkdWseyE1TFgm/ZK w2giFS2jnKS6xxFH5ScplEXo9oBd7YbAsdkGreTAuGiGLZ/eCOHVBnbj35LymmTJ aOiEP0ZbCPpeK0Vx2LgGiRANdP8LJ03Yj3aCY2P7elnFtfOhR6U=
    =NSKb
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)