Hi Mark, Mark H Weaver <m...@netris.org> skribis:
> Ludovic Courtès <l...@gnu.org> writes: > >> Note that there are other places, in addition to GDM, where we >> forcefully reset the UID/GID of the home directory (e.g., for the >> ‘knot-resolver’ service.) >> >> My preferred solution to this would be to unconditionally chown -R home >> directories upon activation (for efficiency, it would be best if we >> could do that if and only if the home directory itself has wrong >> ownership). Thoughts? > > It might be okay to do this in specific cases like /var/lib/gdm, but I'm > very uncomfortable doing it for *all* users, because: > > (1) We shouldn't assume that all files within a home directory are > supposed to be owned by that user. > > (2) We shouldn't assume that all files owned by a user will be within > their home directory. > > (3) We shouldn't assume that all files within a home directory are > supposed to have the same 'group'. I, for one, have sometimes had > subdirectories of my home directory with a different 'group', to > either restrict or grant other users access to selected files or > directories. > > (4) Groups do not, in general, have home directories. > > (5) I consider it unsatifactory for there to be *any* window of time > during system activation when the ownership of files is incorrect. I agree this raises questions and we should take time to think through it. For system accounts though, I think 1–4 do not apply. Perhaps a first step would be to do that for system accounts? >> Note that the ID allocation strategy in (gnu build accounts) ensures >> UIDs/GIDs aren’t reused right away (same strategy as implemented by >> Shadow, etc.). So if you remove “bob”, then add “alice”, “alice” won’t >> be able to access the left-behind /home/bob because it has a different >> UID. To be clear, it’s doing the same as any other GNU/Linux distro. > This mechanism is insufficient, because it only avoids the problem if > you add "alice" at the same time that "bob" is removed. If you remove > "bob" during one system activation, and then later add "alice", then > "alice" might well be able to access bob's left-behind files. > > In the case that I personally witnessed on my Guix system, files within > /var/lib/gdm ended up with 'colord' as their group. That's not good. > > Increasingly, I'm leaning toward the idea that the complete mapping from > names to IDs should somehow be explicitly given as part of the OS > configuration, as I advocated in <https://bugs.gnu.org/36508#26>. > > What do you think? IDs as hash of the user names are interesting because that’d be stateless (conversely, the current ID allocation strategy is stateful: it arranges to not reuse recently-freed IDs.) But like you write, we’d need 32-bit UIDs. In libc, ‘uid_t’ (specifically ‘__UID_T_TYPE’ in typesizes.h) is 32-bit, so it might work rather well in user space. It still sounds like a change with significant implications though, and it’s hard to predict exactly how it would go or what would break. For example, that does away with the system/non-system ranges, and wouldn’t play well with “special” IDs like 0 and 65535. To me, it’s a potential way out, but not a solution for the bug Brendan reported today, nor a change we could implement in the coming weeks/months; the time scale is probably longer. WDYT? Thanks, Ludo’.
