drop obsolete static uid/gid allocations

[Zbigniew Jędrzejewski-Szmek]

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.

(A "soft static" allocation is only needed for two reasons [1]:
- the user is used in the initramfs AND files or processes are carried
  over into the real system,
- the UID is used on shared between systems.

All other packages should use "dynamic" allocation, i.e. create
the user/group in %pre and get any free number.)

I thought I'd file a ticket against setup, but since there's a large
number of items on this list, I decided to ask here first.
Any objection to dropping (from the static list) any of the following?

== No need for static allocation, afaict
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

== The following are completely unused?
console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
pvm, xfs

[1] The guidelines (https://fedoraproject.org/wiki/Packaging:UsersAndGroups)
don't mention the first reason, only the second one. Oh well, changing that
is probably not worth the effort.

Zbyszek

[Jan Pokorný]

On 15/01/17 00:13 +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  == No need for static allocation, afaict
>  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 
ricci+luci can be garbage-collected as not needed since around Fedora 18
anyway.

-- 
Jan (Poki)

[Tomasz Torcz]

On Sun, Jan 15, 2017 at 12:13:16AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  https://git.fedorahosted.org/cgit/setup.git/tree/uidgid has a list
>  of "soft static" uids and gids.
>  
>  == No need for static allocation, afaict
>  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
>  
>  == The following are completely unused?
>  console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
>  pvm, xfs 
  There's also a https://fedoraproject.org/wiki/PackageUserRegistry list,
which contains 'ladvd' user for the package named the same (which I maintain).
I guess I could live which whatever UID sysusers will give me. Now
I have this:

http://pkgs.fedoraproject.org/cgit/rpms/ladvd.git/tree/ladvd.conf.sysusers


-- 
Tomasz Torcz               RIP is irrevelant. Spoofing is futile.
xmpp: zdzichubg(a)chrome.pl     Your routes will be aggreggated. -- Alex Yuriev

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jan 15, 2017 at 12:32:42PM +0100, Tomasz Torcz wrote:
>  On Sun, Jan 15, 2017 at 12:13:16AM +0000, Zbigniew Jędrzejewski-Szmek
> wrote:
>  > https://git.fedorahosted.org/cgit/setup.git/tree/uidgid has a list
>  > of "soft static" uids and gids.
>  > 
>  > == No need for static allocation, afaict
>  > 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
>  > 
>  > == The following are completely unused?
>  > console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
>  > pvm, xfs
>  
>    There's also a https://fedoraproject.org/wiki/PackageUserRegistry list, 
Oh, yet another list. Neither of those lists is hyperlinked from
the guidelines, and it's not entirely trivial to find them.

Anyway, this list appears to be conflict with the list in setup.
Is it used for anything? https://fedoraproject.org/wiki/PackageUserCreation
appears to be rather outdated too.

>  which contains 'ladvd' user for the package named the same
> (which I maintain).
>  I guess I could live which whatever UID sysusers will give me. Now
>  I have this:
>  
>  http://pkgs.fedoraproject.org/cgit/rpms/ladvd.git/tree/ladvd.conf.sysusers 
Yep. If the static uid list is trimmed, it'll be enough to change at
some later point:
- u  ladvd  47  ...
+ u  ladvd  -   ...

Zbyszek

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jan 15, 2017 at 06:00:49PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  On Sun, Jan 15, 2017 at 12:32:42PM +0100, Tomasz Torcz wrote:
>  >   There's also a https://fedoraproject.org/wiki/PackageUserRegistry list,
>  
>  Oh, yet another list. Neither of those lists is hyperlinked from
>  the guidelines, and it's not entirely trivial to find them.
>  
>  Anyway, this list appears to be conflict with the list in setup.
>  Is it used for anything? https://fedoraproject.org/wiki/PackageUserCreation
>  appears to be rather outdated too. 
I replaced that now with a redirect to Packaging:UsersAndGroups.

Zbyszek

[Ondřej Vašík]

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.

>  (A "soft static" allocation is only needed for two reasons
> [1]:
>  - the user is used in the initramfs AND files or processes are carried
>    over into the real system,
>  - the UID is used on shared between systems. 
Third reason is sometimes mentioned - to prevent leak of "sensitive
data" to other "dynamically allocated" when old system user is removed
(and files owned by that users not deleted). But this is more
hypothetical case.

>  All other packages should use "dynamic" allocation, i.e.
> create
>  the user/group in %pre and get any free number.)
>  
>  I thought I'd file a ticket against setup, but since there's a large
>  number of items on this list, I decided to ask here first.
>  Any objection to dropping (from the static list) any of the following?
>  
>  == No need for static allocation, afaict
>  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.
>  
>  == 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.

However, even if I drop these static allocation, I don't think we can
reuse them for any other static allocations anytime soon - 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.

IMHO, drop of these allocation doesn't bring much gain (except cleaner
uidgid file) and brings some potential risks that can show in future.

Regards,
       Ondrej

>  [1] The guidelines
> (https://fedoraproject.org/wiki/Packaging:UsersAndGroups)
>  don't mention the first reason, only the second one. Oh well, changing that
>  is probably not worth the effort. 


>  
>  Zbyszek

[Zbigniew Jędrzejewski-Szmek]

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

[Ondřej Vašík]

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

[Richard W.M. Jones]

On Sun, Jan 15, 2017 at 12:13:16AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  == The following are completely unused?
>  console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
>  pvm, xfs 
I'm going to guess that wnn is related to the Japanese input method of
the same name.  (canna, also a Japanese input method, has its own
static uid & gid registered too).  Both packages run daemons in the
background.

I'm also going to guess that vcsa is something to do with the
/dev/vcs* virtual console devices, although if that's the case then
the group is no longer used.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 16, 2017 at 07:03:31PM +0000, Richard W.M. Jones wrote:
>  On Sun, Jan 15, 2017 at 12:13:16AM +0000, Zbigniew Jędrzejewski-Szmek
> wrote:
>  > == The following are completely unused?
>  > console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
>  > pvm, xfs
>  
>  I'm going to guess that wnn is related to the Japanese input method of
>  the same name.  (canna, also a Japanese input method, has its own
>  static uid & gid registered too).  Both packages run daemons in the
>  background. 
OK, thanks. What's the package for wnn?

canna clearly does not need a static uid, and interestingly, it seems
to use dynamic allocation.  So it's just taking up space in the list ;)

>  I'm also going to guess that vcsa is something to do with the
>  /dev/vcs* virtual console devices, although if that's the case then
>  the group is no longer used. 
It seems to be used under redhat, removed in commit
abbc1c17a0c from
udev/systemd (May 2010). I seems that that file was not under Fedora,
but I'm not sure.

Zbyszek

[Richard W.M. Jones]

On Mon, Jan 16, 2017 at 11:42:26PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  On Mon, Jan 16, 2017 at 07:03:31PM +0000, Richard W.M. Jones wrote:
>  > On Sun, Jan 15, 2017 at 12:13:16AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  > > == The following are completely unused?
>  > > console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
>  > > pvm, xfs
>  > 
>  > I'm going to guess that wnn is related to the Japanese input method of
>  > the same name.  (canna, also a Japanese input method, has its own
>  > static uid & gid registered too).  Both packages run daemons in the
>  > background.
>  
>  OK, thanks. What's the package for wnn? 
A good question!  It took me a while to find, but it looks like we
have now dropped it.  Before it was dropped the package was called
FreeWnn:

  http://pkgs.fedoraproject.org/cgit/rpms/FreeWnn.git

Here is the evidence that it did use the 'wnn' user & group (49.49):

 
http://pkgs.fedoraproject.org/cgit/rpms/FreeWnn.git/tree/FreeWnn.spec?id=...

For reference, in Debian & Wikipedia it's:

  https://packages.debian.org/sid/freewnn-jserver
  https://en.wikipedia.org/wiki/Wnn

>  canna clearly does not need a static uid, and interestingly, it
> seems
>  to use dynamic allocation.  So it's just taking up space in the list ;)
>  
>  > I'm also going to guess that vcsa is something to do with the
>  > /dev/vcs* virtual console devices, although if that's the case then
>  > the group is no longer used.
>  It seems to be used under redhat, removed in commit abbc1c17a0c from
>  udev/systemd (May 2010). I seems that that file was not under Fedora,
>  but I'm not sure. 
Good find.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Fernando Nasser]

On 2017-01-16 2:03 PM, Richard W.M. Jones wrote:
>  On Sun, Jan 15, 2017 at 12:13:16AM +0000, Zbigniew Jędrzejewski-Szmek
> wrote:
> > == The following are completely unused?
> > console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
> > pvm, xfs 
"jonas" is (was?) the userid/group for the OW2 Consortioum Java EE 
Application Server, JOnAS.


>  I'm going to guess that wnn is related to the Japanese input
> method of
>  the same name.  (canna, also a Japanese input method, has its own
>  static uid & gid registered too).  Both packages run daemons in the
>  background.
>
>  I'm also going to guess that vcsa is something to do with the
>  /dev/vcs* virtual console devices, although if that's the case then
>  the group is no longer used.
>
>  Rich.
>

[Michael Scherer]

On Sun, Jan 15, 2017 at 12:13:16AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  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.
>  
>  (A "soft static" allocation is only needed for two reasons [1]:
>  - the user is used in the initramfs AND files or processes are carried
>    over into the real system,
>  - the UID is used on shared between systems.
>  
>  All other packages should use "dynamic" allocation, i.e. create
>  the user/group in %pre and get any free number.)
>  
>  I thought I'd file a ticket against setup, but since there's a large
>  number of items on this list, I decided to ask here first.
>  Any objection to dropping (from the static list) any of the following?
>  
>  == No need for static allocation, afaict
>  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
>  
>  == The following are completely unused?
>  console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
>  pvm, xfs 
I guess xfs is the X font server, we use a dynamic one since ages (and
as we are now moving to Wayland...). See
https://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS

nocpulse was likely linked to a company RH acquired a long time
ago and whose product served as the basis to Satellite/spacewalk.
On RHEL, it is dynamically created, (cf 
https://access.redhat.com/solutions/222323 ), and I think spacewalk is
not packaged in Fedora.

-- 
Michael Scherer

[Przemek Klosowski]

On 01/14/2017 07:13 PM, Zbigniew Jędrzejewski-Szmek wrote:
>  == No need for static allocation, afaict
>  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
>
>  == The following are completely unused?
>  console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
>  pvm, xfs 
FWIW, there's also plugdev which I am involved in evicting from udev 
rules. I think by now it's only used by flashrom

https://bugzilla.redhat.com/show_bug.cgi?id=1330205

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 19, 2017 at 11:33:55AM -0500, Przemek Klosowski wrote:
>  On 01/14/2017 07:13 PM, Zbigniew Jędrzejewski-Szmek wrote:
>  >== No need for static allocation, afaict
>  >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
>  >
>  >== The following are completely unused?
>  >console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
>  >pvm, xfs
>  
>  FWIW, there's also plugdev which I am involved in evicting from udev
>  rules. I think by now it's only used by flashrom
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=1330205 
This reminds me of https://bugzilla.redhat.com/show_bug.cgi?id=1226704,
another fight with windmills.

Zbyszek

[Adam Williamson]

On Sun, 2017-01-15 at 00:13 +0000, Zbigniew Jędrzejewski-Szmek wrote:
>  == The following are completely unused?
>  console, wnn, haldaemon, vcsa, realtime, nocpulse, desktop, jonas,
>  pvm, xfs 
haldaemon was HAL:

https://en.wikipedia.org/wiki/HAL_(software)

whose functionality was taken over by udev, years ago.

beagleindex (from the other list) was for the Beagle desktop search
system:

https://en.wikipedia.org/wiki/Beagle_(software)

which died long ago and is functionally replaced by tracker in current
Fedora. So both of those can certainly go.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net