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

[Brendan Tildesley]

> On 04/13/2021 10:51 PM Mark H Weaver <mhw@netris.org> wrote:
> 
>  
> Hi Brendan,
> 
> Brendan Tildesley via Bug reports for GNU Guix <bug-guix@gnu.org>
> writes:
> 
> > I recently encountered what is likely the same bug. The directory 
> > /var/lib/gdm
> > had the correct permissions gdm:gdm, but all the files inside had something 
> > like
> > 973:gdm
> 
> The underlying problem here, which I've also experienced, is that if you
> reconfigure your system with fewer users/groups, and then later add
> those users/groups back, there is no guarantee that they will be
> assigned the same UIDs and GIDs.
> 
> This problem is made much worse by the fact that files may be left
> around, e.g. in /var, with the old UIDs and GIDs.
> 
> In your case, I guess that the 'gdm' user was previously assigned UID
> 973, but now it has been given a different UID.
> 
> In my case, after reconfiguring to a minimal system and later switching
> back to a full GNOME-based desktop system, I found that many files and
> directories in /var had the wrong owner or group.  Here's what I saw
> before I cleaned things up:
> 
> --8<---------------cut here---------------start------------->8---
> root@jojen ~# ls -l /var/lib/
> total 4
> drwxr-xr-x 1 colord colord    40 Mar 28  2017 colord
> drwx------ 1 995    978       56 Sep  3 02:10 gdm
> drwx------ 1 root   root   30400 Dec 25 01:55 NetworkManager
> -rw------- 1 root   root     512 Dec 25 01:35 random-seed
> drwxr-xr-x 1 colord colord   164 Dec 28  2017 sddm
> drwx------ 1 tor    tor      178 Dec 19 21:28 tor
> drwx------ 1 root   root      20 Sep  5 01:32 udisks2
> drwxr-xr-x 1 root   root     274 Dec 25 01:55 upower
> drwxr-xr-x 1 root   root      86 Mar 28  2017 wicd
> root@jojen ~# ls -la /var/lib/gdm/
> total 4
> drwx------ 1  995    978  56 Sep  3 02:10 .
> drwxr-xr-x 1 root root   750 Dec 25 01:59 ..
> drwxr-xr-x 1  994 colord  64 Sep  3 02:10 .cache
> drwx------ 1  994 colord  54 Sep  3 02:10 .config
> -rw------- 1  994 colord  16 Sep  3 02:10 .esd_auth
> drwxr-xr-x 1  994 colord  10 Sep  3 02:10 .local
> root@jojen ~# 
> --8<---------------cut here---------------end--------------->8---
> 
> Given the fact that existing files and directories in /var can
> *effectively* have their ownership changed, I think that this issue
> could be a security risk.

Yes and they could change for any reason under the sun, and so we have no
choice but to set them right on service activation.

Guix system rollbacks should be a supported feature of Guix, not just a gimmick
that falls out of its design. It should be that a Guix user could leave their
system for 5 years, and then do a guix pull; guix system reconfigure in the year
2026. Perhaps at that time the new system will break, and then its desirable
that they can rollback to the previous generation. So what fixes we put in to 
Guix services today need to consider not just how files could have changed in
the past, but how they might change in breaking ways in the future, within 
reason.
I don't know off the top of my head of any way that can be done other than to
have chmod -R gdm:gdm /var/lib/gdm always executed.
> 
> There's some discussion of this issue at <https://bugs.gnu.org/44944>,
> although I'm not sure that Danny's suggested solution is practical.
> 
> 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.
> 
> What do you think

Wouldn't that imply that uids could be randomly different on different systems
with the same configuration, and then remain statically different permanently?
We want as little randomness and moving parts as possible. It's yet another
way the system is not actually Functional, but has state.

Seems this bug spans 3 or so different bug reports. In 
http://issues.guix.gnu.org/45571
I commented that Nix uses hard coded id's, sorta like how ports are allocated
for a purpose:

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix

Perhaps you are thinking of other kinds of security issues that could be caused 
that
I'm not thinking of. In that case maybe Nix devs have already made the best 
choice by
making them static?

... After all, if the permissions can change, then it is possible another user 
could
actually modify the contents of /var/lib/gdm its self, thereby infecting other 
users,
if for some reason that other malicious user gets allocated that ID.
That further points towards static ID's like Nix has as a solution.