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)? > 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. 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. > 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) ? 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. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
