From: lars@beagle-ears.com
Thanks to all who provided helpful hints. I think I got the problem
resolved. It turned out that out of the 50 or so group IDs that had
duplicate (in one case quadruplicate) entries in /etc/group, the
only one of them that owned files in the root file system
tagged wih a GID that was not the lowest numbered one was "smmsp",
and it was very simple to chan the gid on those. So after that I
just deleted any duplicates and kept, the lowest numbered entry.
I use Fedora. GIDs are dynamic: If the packager feels that
UIDs and GIDs are needed, the post-install or post-update script
create them. Where it feels they should be, has changed over time.
At one point they were counting backwards from 499, later they
counted backwards from 999. But some of the scripts must have been
poorly written, because I had several cases where there were
duplicate entries with the same GID.
On 2026-01-01, Rich wrote:
> Lars Poulsen wrote:
>> I found that GID 51 and GID 486 were both in /etc/group as the
>> group smmsp (sendmail sending profile?). And it turns out that
>> there are a number of these:
>> mailnull 47 and 487
>> apache 48 and 489
>> smmsp 51 and 486
>> openvpn 994 and 982
>> ...
>> And there are probably also such problems on the user-id side.
>
> Best guess, some "upgrade" from Version[x-1] to V[x] of your chosen
> distro changed the group allocation numbers, and inserted new records
> without removing the old ones.
>
>> Clearly, these need to be consolidated, but then after that, the
>> file systems have to be scanned and corrected so that all the SUID
>> and SGID bits get moved to the chosen survivor entry.
>>
>> The scripts to do this will be a pain to write, so I wonder
>
> Not really. GNU find (if you are running a Linux distro) has options
> to find files by group id (note, see elsewhere in the find manpage for
> how to specify the less than/greater than choice):
>
> -gid n File's numeric group ID is less than, more than or exactly n.
>
> And, what you most likely want to do is simply change group ownership
> of anything owned by the old group (whether sgid or not) to the new
> group).
>
> So something like:
>
> find / -xdev -gid 47 -print0 | xargs -0 chown :487
>
> Will change group ownership of everything owned by gid 47 to gid 487.
>
> Note, the -xdev omits walking down other mounted filesystems. If you
> do in fact want to walk down those other filesystems, omit the -xdev
> switch.
>
> Repeat other find lines for each group/user id you need to migrate.
>
>> Of course I also wonder how (and how long ago) it happened.
>> Part of the origin story is certainly that 10-15 years ago
>> the reserved range of UIDs and GIDs ended at 499 and user accounts
>> started at 500 instead of 1000 where they are now.
>
> You'd have to step back through each 'release notes' for your distro to
> see if somewhere they made a note of changing the defaults assigned to
> the groups.
>
>> Part of the immediate cleanup will be moving old user-ids out of the
>> 500-999 range. When doing that, it would be good to also align the
>> UIDs and GIDs of the users. (Which means setting aside a range
>> groups like "family", "friends", "coworkers" that do not have a
>> unique user associated.)
>
> If you also have userid numbers that need 'moving', then find also has
> a "-uid n" to find files owned by id 'n'.
>
>> It seems to me, that the best solution would be to provide a hook
>> in the installation process to bring in the old passwd and group
>> files to merge them in.
>
> Yes, but then that also depends upon whether your distro is meant to be
> a 'rolling release' style, where there is one install and then
> "updates" forever -- in which case yes the distro should handle this
> kind of migration as part of that upgrade process. But if your distro
> presumes that 'upgrades' are done by "install new version" instead of
> "upgrade old version" they may omit migration hooks because their
> assumption is "/ is empty when we install".
>
>> And by the way, is there a canonical list of "preferred" values
>> for system service UID and GID?
>
> If there is, it might be in the old FHS (Filesystem Hierarchy Standard)
> or nearby to that document. But beyond uid/gid zero being special,
> there is no difference between uid 2 and uid 2000 as far as the system
> is concerned. So I suspect there's no particular 'standard' (in the
> same way that there are standard TCP port numbers for various
> services).
Most of the work to diagnose the problem was done by using a Perl
subroutine I already had on hand, which recursively scans all files
under a starting point, allowing a callback for each directory and each
file encountered along the way. I have been using this for maintaining
my large photo archive. It is not unlike "find" in its uses.
So I created a list of every file in the root file system whose
ownership was not root:root, indicating its numeric uid:gid.
That turned out to be a pretty small number.
I picked this particular post to respond to, because others might
find the tips on how to use "find" usefuls, so this is the post
you might want to save in your notebook.
The tips I found most useful (since I use find regularly) were
the references to "pwck" and "grpck".
Most of the errors found by "grpck" pertaining to want items
to be added to "gshadow" I ignored. I think that gshadow entries
are likely added as needed.
--
Lars Poulsen - an old geek in Santa Barbara, California
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
