Hi, Mark H Weaver <m...@netris.org> 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 *never* deleted automatically. They are only added > automatically, but never removed unless you explicitly ask to remove > them. So, this problem does not arise in practice. >> 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 >> range of those mappings. If we’re just worried about ID allocation, we could keep state in, say, /etc/previous-uids, and feed that as input to the (gnu build accounts) allocation code. Thoughts? Maxime Devos <maximede...@telenet.be> skribis: > This seems rather convoluted to me. Why not reuse /etc/passwd and > /etc/groups? > My suggestion: > > 1. *never* automatically delete users/groups from /etc/passwd, /etc/groups > (I thought that was how Guix already worked ...) > 2. as users and groups appearing in /etc/passwd and /etc/groups, but not > in the operating system configuration can be confusing, change the comment > string of these users and groups, to something like > > "account removed" > > Add a group 'user-graveyard' for (3), and move these 'pseudo-removed' users > to the 'user-graveyard' group. > 3. Don't forget to remove graveyard users from all groups (except > user-graveyard), > make sure the graveyard users can't log in anymore ... (Perhaps add a rule > to > the SSH and PAM configuration that forbids logging in to graveyard > accounts, > by checking whether the user is in the 'user-graveyard' group?) Problem is that things like GDM would still propose those old accounts (unless maybe their password is uninitialized, I’m not sure; but it’s still hacky.) Thanks, Ludo’.
