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

Hi Maxime, Maxime Devos writes: > On Thu, 2021-04-15 at 14:58 -0400, Mark H Weaver wrote: >> Maintain historical mappings from user/group names to UIDs/GIDs, perhaps >> in some file in /etc, where entries are added but *never* automatically >> removed. When allocating UIDs/GIDs, we would avoid

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

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >>> Maintain historical mappings from user/group names to UIDs/GIDs, perhaps >>> in some file in /etc, where entries are added but *never* automatically >>> removed. When allocating UIDs/GIDs, we would avoid any UIDs/GIDs in the >>

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

Hi, Mark H Weaver skribis: > It's true that if you delete a user or group on another distro and then > re-add it, it might not be assigned the same UID/GID. That much is the > same as any other distro. > > The key difference is this: On Debian, at least in my experience, users > and groups are

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

Hi Mark, Mark H Weaver skribis: > This particular issue is easily addressed. It's easy enough to find a > function from 31-hash values to 32-bit IDs that's injective and avoids > any chosen subset of special IDs, as long as there are fewer than 2^31 > special IDs. > > Simply adding 65536 (or ev

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

On Thu, 2021-04-15 at 14:58 -0400, Mark H Weaver wrote: > Ludovic Courtès writes: > > > Mark H Weaver skribis: > > > > > 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 woul

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

Hi Ludovic, Ludovic Courtès writes: > 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’ > (speci

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

Hi Ludovic, Ludovic Courtès wrote: >>> 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 /ho

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

Hi Mark, Mark H Weaver skribis: > 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 -

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

Ludovic Courtès writes: > Mark H Weaver skribis: > >> 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

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

Ludovic Courtès writes: > My preferred solution to this would be to unconditionally chown -R home > directories upon activation I also wonder if this could lead to security flaws similar to CVE-2021-27851 , but perhaps 'chown' has been written carefully to avoid such p

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

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 e

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

Hi Brendan, Brendan Tildesley writes: > 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.

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

Hi, Brendan Tildesley skribis: >> On 04/14/2021 12:32 PM Ludovic Courtès wrote: [...] >> The patch Brendan posted LGTM (though I’m surprised the directory itself >> can have the right UID/GID while files inside it don’t; perhaps this was >> made possible by 2161820ebbbab62a5ce76c9101ebaec54dc

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

> On 04/14/2021 12:32 PM Ludovic Courtès wrote: > > > Hi Mark, > > Mark H Weaver skribis: > > > Brendan Tildesley via Bug reports for GNU Guix > > writes: > > > >> I recently encountered what is likely the same bug. The directory > >> /var/lib/gdm > >> had the correct permissions gdm:gdm

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

Hi Mark, Mark H Weaver skribis: > Brendan Tildesley via Bug reports for GNU Guix > 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 underlyin

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

> On 04/13/2021 10:51 PM Mark H Weaver wrote: > > > Hi Brendan, > > Brendan Tildesley via Bug reports for GNU Guix > 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 somet

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

Hi Brendan, Brendan Tildesley via Bug reports for GNU Guix 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 experi

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

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 a43e9157ef479e94c19951cc9d228cf153bf78ee is supposed to fix this (duplicate bug 37423) but it only checks the permissions of /var/