> On 04/13/2021 10:51 PM Mark H Weaver <m...@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.