bug#36508: GDM files have incorrect owner after temporarily removing service

[Mark H Weaver <mhw@netris.org>]

Ludovic Courtès <ludo@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.

>> 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 <https://bugs.gnu.org/36508#26>.

What do you think?

     Thanks,
       Mark