So deluser was doing the right thing, right? The bug is how you got into this state? Either the adduser for the high uid should have checked for it being a delegated subuid, or the adduser which added the subuids to the lower subuid should have refused when the higher subuid existed as a uid.
On Tue, Mar 08, 2022 at 05:31:41PM +0000, Ben Harris wrote: > I ran into a problem very similar to the one described in Debian bug 868568: > deleting a user with a UID < 100000 failed because of a process that was > running as a user with a UID >= 100000. It turned out to be because the > larger user ID was recorded in /etc/subuid as a subordinate user-ID for the > lower-numbered user. Blanking out /etc/subuid and /etc/subgid caused > deluser to behave as normal. > > According to login.defs(5), the default range of subuids starts at 100000. > If you're using UIDs over 100000 for normal users then you probably want to > change that (or find a way to disable subordinate user-IDs entirely). > > -- > Ben Harris, University of Cambridge Information Services. > > _______________________________________________ > Pkg-shadow-devel mailing list > Pkg-shadow-devel@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel _______________________________________________ Pkg-shadow-devel mailing list Pkg-shadow-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-shadow-devel
