Ludovic Courtès 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. >> Here's one idea: when activating a system, *never* delete users or >> groups if files still exist that are owned by those users/groups. >> Checking all filesystems would likely be too expensive, but perhaps it >> would be sufficient to check certain directories such as /var, /etc, and >> possibly the top directory of /home. > > How would you determine which directories to look at though? What if we > miss an important one? Yes, that's a good point. I suppose that my idea above is not satifactory either. > 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. 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 . What do you think? Thanks, Mark