Dear Maintainer, Setting "USERGROUPS_ENAB no" does nothing, the group for creating new files stays the same, with the same umask. This applies to both existing users as newly created users. I would expect new files to have "users" as group instead of their own username and have an umask of 022. The same applies to "UMASK 022", entered values are not used.
Control: reassign -1 src:pam You didn't really say which thing you are using which does not respect the configured values. I assume what you are seeing is caused by the default PAM configuration. IIRC there was some change for trixie. Reassigning to PAM. @Sam: I'm open to dropping config directives from login.defs, let me know. Best, Chris
* Bob Rosbag <debian@bobrosbag.nl> [250831 22:20]: Can you explain -how- you created the new user? useradd is supposed to look at USERGROUPS_ENAB, but other tools might not. If PAM ignores UMASK in /etc/login.defs, I'll delete it from /etc/login.defs. I think pam_umask is supposed to read it? login(1) ignores it. I'll wait for Sam to chime in here. Chris
I created a new user with: adduser [username] As I understood, adduser is higher level frontend which uses useradd, so USERGROUPS_ENAB should be processed. From the debian umask wiki, UMASK in /etc/login.defs should finally work since Trixie, it never worked in Bookworm and earlier versions. https://wiki.debian.org/Debate/umask The same seems to apply to Arch linux. Arch recently (2023) changed umask configuration from /etc/profile to /etc/login.defs. https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ Bob
* Bob Rosbag <debian@bobrosbag.nl> [250901 13:44]: adduser has its own configuration, see adduser.conf(5), specifically the USERGROUPS setting. Chris
Ok, I tested a couple of things with 'useradd' now and it does indeed work. But for UMASK to work, USERGROUPS_ENAB has to be set to 'no', otherwise UMASK does not work. When set to 'yes', it accepts all UMASK values. It even works for kde/plasma. But only for newly created users. I tried to find where these settings are stored/changed so I can use it for existing users but could not find the config files where these settings are stored. For plasma/kde it still seems impossible to achieve UPG with UMASK 022, you have to disable the UPG and then for newly created users you can choose the UMASK. Maybe the systemd UMask works now that UPG is disabled. I will check later. Emails to bug.debian.org are working now.
Did some more testing. useradd uses USERGROUPS_ENAB in /etc/login.defs and adduser uses USERGROUPS in /etc/adduser.conf This is only used for creating new users. Active users, independent by which tool they were created, use UMASK in /etc/login.defs (since Trixie). When the primary group name is the same username, then group permissions are equal to owner permissions. The 'group' entry in the UMASK value is ommited. Only way to get a different umask for 'group' relative to 'owner' is setting umask in /etc/profile. Services/applications started by systemd don't use /etc/profile and 'UMask' in systemd seems non-functional so there is no way to get an effective umask of 022 in kde/plasma. I only use single user systems and prefer UPG with umask 022. I don't share files with other users on my systems, but I do make system config files as a user. When deploying these files to the system and changing to root:root, I now need an extra step to remove the write permission from 'group' for these files. My options at the moment are basically or changing to a non systemd started DE (from Plasma to xfce for example) or disabling UPG on my systems by changing the primary group to 'users' and 'chmod' all my 664 files and 775 directories to 644/755 and 'chown' the group to 'users' (from jack:jack 664 to jack:users 644) It also seems a security concern that this change was not prominently communicated in the release notes of Trixie. Not being aware of this change, could have security implications in certain setups.
Bob> Did some more testing. useradd uses USERGROUPS_ENAB in
Bob> /etc/login.defs and adduser uses USERGROUPS in
Bob> /etc/adduser.conf This is only used for creating new users.
Bob> Active users, independent by which tool they were created, use
Bob> UMASK in /etc/login.defs (since Trixie). When the primary group
Bob> name is the same username, then group permissions are equal to
Bob> owner permissions. The 'group' entry in the UMASK value is
Bob> ommited. Only way to get a different umask for 'group'
Bob> relative to 'owner' is setting umask in
Bob> /etc/profile. Services/applications started by systemd don't
Bob> use /etc/profile and 'UMask' in systemd seems non-functional so
Bob> there is no way to get an effective umask of 022 in kde/plasma.
This is by design.
I think the idea is that you want to be able to set the group bits in
the mask to read only if some users don't have usergroups (system users
etc), but to get write bits enabled for users where usergroups are in
use.
Here's the code.
if (options->usergroups)
{
/* if not root and username is the same as primary group name,
set umask group bits to be the same as owner bits
(examples: 022 -> 002, 077 -> 007). */
if (pw->pw_uid != 0)
{
struct group *grp = pam_modutil_getgrgid (pamh, pw->pw_gid);
if (grp && (strcmp (pw->pw_name, grp->gr_name) == 0))
{
mode_t oldmask = umask (0777);
umask ((oldmask & ~070) | ((oldmask >> 3) & 070));
}
}
}
It seems like for your use case you could turn off usergroups but
manually set up a user group for your single user.
Also, there's apparently a mechanism to set user umask from the gecos
field in /etc/passwd. That overrides the above code.
The gecos field was the only option I did not try yet but it does indeed work. Thanks! chfn -o "umask=0022" jack Resulted in jack:jack 644 I already converted everything to 1000:100 or bob:users with umask 022 and disabling UPG is also easy to implement within live-build images. But good to know the gecos field works.
While the GECOS field does the job, it is cumbersome to set it for all users (new as well as existing) on multi-user systems. In that context, the changes in trixie qualify as a severe security bug: I'm administering a bunch of such systems, I upgrade them to trixie, and *poof*, users in the same group can _write_ to each other's files and directories(!!!) What's worse, the changes in trixie were made without much of a warning or update to the documentation. I found multiple places where it is either stated (paraphrased) that the default system-wide umasks are controlled by a combination of UMASK and USERGROUPS_ENAB in login.defs , or that a line like this in /etc/pam.d/common-session does the job: session optional pam_umask.so umask=077 (see for instance https://www.debian.org/doc/manuals/securing-debian-manual/ch04s11.en.html#idm1514 ) To be clear, this is not the case because usergroups has been enabled at compile time and overrides umasks even on the pam_umask.so "command-line". In order to work properly, "nousergroups" needs to be added to the pam_umask line in /etc/pam.d/common-session : session optional pam_umask.so nousergroups umask=077 Places where this is stated explicitly are hard to find at best; all sources on the internet (including the Debian manual; see above) seem to make the reasonable assumption that usergroups is not compiled into pam_umask.so . You won't believe how much time it has cost me to find this solution. In my opinion, this change in trixie is a blatant violation of the Principle of Least Surprise.
Sorry, I figured out what was going wrong in my specific case just after sending the last message. Turns out it are not all my users whose files and directories are group-writable - only mine. The users are meant to be able to read one another's files on the shared machines by default, so they're all in the same group. But they're not meant to be able to read all the sysadmin's files, so my primary group is a separate group with the same name as my login name. What I intended as an extra layer of protection turned into a liability when upgrading to trixie. Because I often share files with users by issuing "chown :joint-group some-file", and this is a bit of a problem if the files are unexpectedly group-writable... Lesson learned: letting the behavior of file access permissions depend on comparing a login and group name is prone to cause surprises, if not security-critical edge cases. At the end of the day, the impact of my case is limited, but this is a change I wouldn't confidently push out into the world if I were managing a popular Linux distro...