5

I have two systems, A and B. A is Ubuntu 16.04, and B is Ubuntu 20.04. Each has a utility user 'rufus' defined on it. 'rufus' has no login on either system.

I want to understand why 'rufus' has different default umask values between the two systems. On system A (16.04), I get

$ sudo -u rufus sh -c umask
0022

On system B (20.04), I get

$ sudo -u rufus sh -c umask
0002

Running umask for both my own user and for 'root' returns 0022, the expected default, on both systems. Whatever the difference is, it seems to relate to some property specific to 'rufus'.

Here are the things I've considered:

1) system users

Some Linux systems define different default umasks for system users than for regular users.

On system A (16.04), 'rufus' has

$ id rufus
uid=999(rufus) gid=999(rufus) groups=999(rufus)

On system B (20.04), 'rufus' has

$ id rufus
uid=114(rufus) gid=119(rufus) groups=119(rufus)

On both systems, /etc/login.defs has a default umask of 022 and the system user window commented out

UMASK           022
# System accounts
#SYS_UID_MIN              100
#SYS_UID_MAX              999

but /etc/adduser.conf has

FIRST_SYSTEM_UID=100
LAST_SYSTEM_UID=999

indicating that 'rufus' is a system user on both systems (that is, UID > 99 and UID < 1000). So it doesn't seem like this explains the difference in default umask.

2) Login scripts

A user's default umask can be set by login scripts, either global ones like /etc/profile or user-specific ones like ~/.profile. 'rufus' has no login, so these files shouldn't affect what umask returns, because they are never processed.

To be thorough, however, I double-checked the files

/etc/profile
/etc/bash.bashrc
~rufus/.profile

on both systems ('rufus' does have a home folder). None of them set a value for umask. So for a couple of reasons, it doesn't seem like this explains the difference in default umask.

3) /etc/passwd

A user's 'umask' can be set in /etc/passwd.

On System A (16.04):

rufus:x:999:999:,,,:/home/rufus:/usr/sbin/nologin

On System B (20.04):

rufus:x:114:119::/home/rufus:/usr/sbin/nologin

Neither of these set 'umask', so it doesn't seem like this explains the difference in default umask.

4) libpam-umask

I know very little of this, but I understand it can be used to set the umask value for a user. On both systems, libpam-umask is provided by the package libpam-modules. This package installed on both systems, but I have never used it or configured it. On both systems, the config files /etc/pam.d/common-session and /etc/pam.d/common-session-noninteractive have no umask setting on the line

session    optional    pam_umask.so

so unless there's somewhere else I need to look, this doesn't seem to explain the difference in default umask.

That's all I can think of. What else can explain the difference in what umask returns for 'rufus' between the two systems?

One question I'd like answered in particular is: When Ubuntu sets a default umask for all system users (UID 100-999), in what file is this set?. This seems to be yet another piece of Linux's signature "secret information".

mook765
  • 14,911
  • 5
  • 35
  • 67
Borea Deitz
  • 263
  • 1
  • 10
  • 1
    I wonder if this is due to the (default iirc) pam_umask `usergroups` setting and/or the setting of `USERGROUPS_ENAB` in the /etc/login.defs file? (*"If the user is not root and the username is the same as primary group name, the umask group bits are set to be the same as owner bits (examples: 022 -> 002, 077 -> 007)"*) – steeldriver May 24 '21 at 19:51
  • @steeldriver I saw that. Both of my `login.defs` have the additional condition that uid=gid for this, though, and that's the opposite of what I see. In my case, I get 022 -> 002 for the case where uid != gid (System B, 20.04), so I'm not sure what to make of it. `USERGROUPS_ENAB` is set to "yes" on both systems, for what it's worth. – Borea Deitz May 24 '21 at 19:58
  • Read `man pam_umask`. for a full explanation. Look at others in `man -k pam`. – waltinator May 24 '21 at 20:59
  • @Terrance Yes, the UID and GID differ between systems. I'm asking about the default value of umask, which is a different value. – Borea Deitz May 24 '21 at 21:11
  • @waltinator `man pam_umask` doesn't have a full explanation of anything, unfortunately. What useful information it does provide is already addressed in my question. – Borea Deitz May 24 '21 at 21:14
  • @Terrance Most if not all Linux systems have different default umask values for different UID blocks, so the user's UID is relevant to what default umask it's given – Borea Deitz May 24 '21 at 21:18
  • @Terrance Thank you for the reference, but everything in that link is already covered in my question. – Borea Deitz May 24 '21 at 21:47

1 Answers1

4

I think I figured this out. In the /etc/login.prefs in 20.04 the following is stated:

# If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value
# for private user groups, i. e. the uid is the same as gid, and username is
# the same as the primary group name: for these, the user permissions will be
# used as group permissions, e. g. 022 will become 002.

This might honestly be a bug in 16.04 when running the command sudo -u username sh -c umask. This is the only thing I can come up with. On my test systems I get the following output.

16.04:

terrance@terrance-1604:~$ id
uid=1000(terrance) gid=1000(terrance) groups=1000(terrance),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),128(sambashare)
terrance@terrance-1604:~$ umask
0002
terrance@terrance-1604:~$ sudo -u terrance sh -c umask
0022

20.04:

terrance@terrance-ubuntu:~$ id
uid=1000(terrance) gid=1000(terrance) groups=1000(terrance),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),118(lpadmin),126(sambashare),132(vboxusers)
terrance@terrance-ubuntu:~$ umask
0002
terrance@terrance-ubuntu:~$ sudo -u terrance sh -c umask
0002

As it appears they both support the exact same commands and have the exact same wording in the /etc/login.prefs. But 16.04 appears to not read into the user correctly like it does in 20.04. It looks like a bug, but since 16.04 is now EOL they will not update for bugs anymore.

Hope this helps!

Terrance
  • 39,774
  • 7
  • 116
  • 176
  • This is what I thought initially (hence [my comment](https://askubuntu.com/questions/1340415/why-does-a-users-umask-values-differ-between-two-systems#comment2289328_1340415)) however `man pam_umask` and the module source says it's actually the user and primary group *names* rather than numeric IDs (`strcmp (pw->pw_name, grp->gr_name) == 0`) that are compared, and in fact (as the OP has pointed out) it's the system where `gid == uid` that's **not** applying the `usergroups` rule (which should change the first `2` to `0`). I wonder if that was different in 16.04? – steeldriver May 24 '21 at 22:39
  • @steeldriver It is very possible it could have been different. OP though did not put the contents of the /etc/group file that shows what the name of group to match. But then again, we no longer support 16.04 anyway. I have been seeing lots of these comparison questions here for 16.04 and 20.04 lately and I am not sure why. – Terrance May 24 '21 at 22:45
  • 2
    Fair enough - so I suppose the answer is that the *supported* release does what it says on the tin (i.e. promote `0022` -> `0002` since the username and primary group name are both `rufus`), and whatever 16.04 does is off-topic... – steeldriver May 24 '21 at 22:51
  • I am attempting to migrate a webapp that worked on 16.04 to a fresh 20.04 install, and it's broken on 20.04. Nothing about the webapp changed, so I'm comparing what else changed between 16.04 and 20.04 to figure out what the source of the error is. That's the reason for the comparison posts. – Borea Deitz May 24 '21 at 22:55
  • @steeldriver Thanks for that last comment so I corrected my answer. – Terrance May 24 '21 at 22:55
  • @BoreaDeitz It is not only you, I have seen several others doing it here too. Just an observation I had. – Terrance May 24 '21 at 22:56