From Fedora Project Wiki

Why dynamic user creation is considered as bad...

Reusing of UIDs

Usual and common packaging-practice is to give free any used resources on removal. This includes UIDs and GIDs also, which can lead to security implications. E.g. assume a package "A" which creates an user "a" with the UID x. A service/program running as this user places some sensitive information in its /var/lib/A directory which are readable only by a. Such information can be e.g. a dhcp-leases file or CA keys.

| # rpm -U A
| # id a
| uid=135(a) gid=135(a) groups=135(a)
| # su - a -c do-secret-things
| # ls -l /var/lib/A
| -rw-------    1 a        a              24 Sep 12 16:25 a-dark-secret

Now, you find a better package or are unhappy for package "A" and remove it with "rpm -e A". This will remove the user a also and will free the used UID x. Since the sensitive files created above are not content of the package, they will remain in the filesystem, still owned by UID x.

| # rpm -e A
| # ls -l /var/lib/A
| -rw-------    1 135      135            24 Sep 12 16:25 a-dark-secret

Now, you install a package "B" which creates an user "b". With dynamic user creation, this user can get the UID x which was assigned to a formerly and can read the secret information therefore.

| # rpm -U B
| # su - b
| $ cat /var/lib/A/a-dark-secret
| The secret is 'rosebud'
| $ id
| uid=135(b) gid=135(b) groups=135(b)

When using the methods from fedora-usermgmt, the user a and b will get semi-static and different UIDs and b can not read this file.

Filesystem sharing

It is common that directory like /usr or /usr/share are shared between several machines. This is solved by having one (NFS,AFS,...) server which is responsible for filling these directories with live, and clients which do not touch them. When having something like

| %_netsharedpath  /usr

in the client's /etc/rpm/macros file, both server and clients can install a package C with the same

| # rpm -U C

command. Problems occur, when C creates a user dynamically and ships files owned by this user.

E.g. assume, C owns the setuid'ed program /usr/bin/do-c and the directory /var/lib/C:

| # rpm -ql C
| -r-s--x--x    1 c    root              0 Sep 12 17:00 /usr/sbin/do-c
| drwxr-xr-x    2 c    root              0 Jul 31 17:00 /var/lib/C

When the server installs this package and the user gets created, it becomes the number y. On the clients (which may not have all the packages of the server installed), the user c gets a different UID z.

| ~[root@server] # id c
| uid=136(c) gid=136(c) groups=136(c)
| ~[root@client] # id c
| uid=135(c) gid=135(c) groups=135(c)

Because of this different UIDs, the /usr/sbin/do-c program would run as an undesired user on the clients:

| ~[root@server] # ls -ld /usr/sbin/do-c /var/lib/C
| -r-s--x--x    1 c        root            0 Sep 12 17:00 /usr/sbin/do-c
| drwxr-xr-x    2 c        root         4096 Sep 12 17:01 /var/lib/C
| ~[root@client] # ls -ld /usr/sbin/do-c /var/lib/C
| -r-s--x--x    1 136      root            0 Sep 12 17:00 /usr/sbin/do-c
| drwxr-xr-x    2 c        root         1024 Sep 12 17:01 /var/lib/C