Zbigniew Jędrzejewski-Szmek píše v Po 16. 01. 2017 v 23:26 +0000: > On Mon, Jan 16, 2017 at 10:45:00AM +0100, Ondřej Vašík wrote: > > Zbigniew Jędrzejewski-Szmek píše v Ne 15. 01. 2017 v 00:13 +0000: > > > https://git.fedorahosted.org/cgit/setup.git/tree/uidgid has a list > > > of "soft static" uids and gids. > > > > > > Currently FPC has a process for allocating new numbers on this list, > > > but here's a number of static uid/gid allocations from old times, > > > which are not necessary. Dropping them will allow those numbers to be > > > used in the dynamic pool, reducing the risk of exhaustion of system > > > uids or gids. > > > > Dynamic pool uses static id area only in the worst case when uid/gids > > 200-999 are already allocated. > > From the users listed down only "games" user is created by default - so > > unless the package that creates the uid/gid is installed, their ids can > > theoretically be used for dynamic ids creation. If they are on the > > system, you will not get anything by removal of static allocation - as > > they will occupy some dynamic id anyway. > > OK. So this makes the removal less useful than I thought, more of a cleanup > then a user-visible change. I'd still like to go through with it though. > > > > games, man, slocate, squid, named, postgres, mysql, nscd, > > > rpcuser, rpc, rpm, ntp, mailman, gdm, utempter, apache, smmsp, > > > tomcat, frontpage, nut, beagleindex, avahi, tcpdmp, privoxy, radvd, > > > imap, majordomo, polkituser, screen, clamav, saned, mock, ricci, luci > > > > I agree for some of these I don't see any need for static id allocation > > - and they have static id allocated only for historical reasons. (typo > > s/tcpdmp/tcpdump btw.). > > I don't see imap in the uidgid file. > > I was copying the stuff by hand, digging for information about packages > online, and I must have copied from the wrong column. There is cyrus, saslauth > in the uidgid list, but those seems to fall into the same category as > mysql/apache/tomcat mentioned elsewhere in the thread, that people want > to keep static because it's more likely to be shared over the network. > > > > == The following are completely unused? > > > console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas, > > > pvm, xfs > > > > From 45 ids listed above, 40 were reserved before I got maintenance of > > the setup package (2008). Only 4 (saned, mock, ricci, luci) were added > > by me and 1 is not in uidgid file at all. > > Reason for mock is explained in > > https://bugzilla.redhat.com/show_bug.cgi?id=928063#c0 . For ricci/luci, > > I expect reason for the static id is they belong to High > > Availability/Cluster... However, they were dropped meanwhile. Saned > > probably doesn't need static id, though. > > Oh, OK. Maybe we could add comments to the uidgid list with links to the > tickets (at least going forward)?
I mention the bz numbers (or fpc ticket) in the spec file changelog entries . But if we do some cleanup, some brief justification/link can be reasonable - especially for cases like mock. Alternatively, I can keep it in srpm/source uidgid file only, and strip it during the packaging (and point to git location via comment where the explanation can be available). > > However, even if I drop these static allocation, I don't think we can > > reuse them for any other static allocations anytime soon > I grok this part > > > - as this could > > mean dynamic allocation for the new potentially statically allocated > > account - if the system was maintained via upgrades from older > > Fedoras/RHELs/CentOS. > But not this. If a system has been continually upgraded and has the > "soft static" user actually created in the local user database, if the > allocation is dropped, it will not be removed from the local user > database, so for those systems nothing would change. True. > For systems which do *not* have the de-allocated user in the local > database, if a package which creates that user will be installed, an > uid for that user will be pulled from 200-999, and if that range is > completely full, from the soft-static range, as you said above. So > again, very little changes. But if I potentially assign the dropped id to other user/group, it can be created with different uidgid. Thanks to "soft" static user creation, it will create the user with other, dynamic system id. But this can cause troubles if there is real need for same static id on multiple machines in the network. > > IMHO, drop of these allocation doesn't bring much gain (except cleaner > > uidgid file) and brings some potential risks that can show in future. > > I think a cleaner uidgid file is useful: right now that list is a bit > of a museum piece of history of fedora. > OK, so what you as the maintainer, think is worth doing: > a) drop really unused entries (approximately my second list with some > corrections) > b) drop used-but-unneeded entries (approx. my first list) > ? I'd probably go with a) now and later with some reduced b) . Note that removals of b) would mean filed bugzillas against the packages owning the user/group creation, as creating static uid/gid without reservation in setup package is against Fedora packaging guidelines. > With ~195 entries the pool of soft static uids is getting low. So > *some* changes will be needed. A cleanup of this list should be a useful > first step. I agree with cleanup - especially in those no-longer-in-use cases. I will probably keep some "history-uidgid" file in the git repo, so I don't have to remember which static id have been used in the past. I'd be a bit conservative though - not removing the id allocation where it can make sense because of the backups or cloning virtual disks. However "wc -l" is not your friend in the case of uidgid file. No way 195 entries is already in the static pool. Actually MUCH lower amount of ids is allocated. This wrong assumption almost everything is allocated now contributed to overtaking of the "allocation approvals" by FPC ( https://fedorahosted.org/fpc/ticket/269 ). Allocated uids bellow 200: 123 ( something like $(cut -f2 uidgid | sort | uniq | grep ^[0-9] | wc -l) (and -1 because of nfsnobody above 200)) allocated gids bellow 200: 151 ( something like $(cut -f2 uidgid | sort | uniq | grep ^[0-9] | wc -l) (and -1 because of nfsnobody above 200)) Note just 4 static reservations happened in the last two years (due to big pushback against new ones). 0-100 range was depleted in ~2009... Regards, Ondrej > > Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
