On Monday, 9 August 2021 7:00:59 PM ACST Thorsten Kukuk wrote:
On Mon, Aug 09, Ludwig Nussel wrote:
Ubuntu on the other hand seems to have patched pam_umask to read /etc/login.defs for USERGROUPS_ENAB and sets umask based on that. So login shells also have 0002.
If we do that, we have a big security problem, as USERGROUPS_ENAB tells you only if in the future created users will have private user groups, but does not tell you anything about existing ones. So all users in a shared "users" group would suddenly have a UMASK 0002 and all other people could write to newly created files of this user.
Anyway IMO if we already change an age old default of SUSE systems then please let's do it with all benefits. Just have to decide whether to copy Fedora or Ubuntu.
If you have a got solution how to handle existing, non private user groups using accounts... Neither the Ubuntu nor the Fedora way solves this.
Thorsten
When I setup my systems, all users go into the "users" group by default, and folders under /home/ are 0700. Folders intended to be shared between users have their group set to "users" and appropriate permissions (either r-x or rwx) are set. I'm also going to experiment with setfacl - that could provide finer-grained control if each user has their own group, allowing each user "group" to be added (with it's own permissions mask) to specific folders, but filesystems have to be mounted with the correct options for that to work, as I understand it. I don't know how practical that is to retro-fit to existing users/folders/ systems. In most of my use-cases though, I'd be more likely to mimic the AD idea of a primary group for all users ("users") and supplementary groups used in ACL's to control access to specific files/folders via setfacl and permissions for specific groups. Access for specific users can be turned on/off by adding/ removing them to/from specific groups. Not sure how that plays into the current discussion - just some thoughts that came to mind while reading. Regards, Rodney. -- ================================================================================================================== Rodney Baker rodney.baker@iinet.net.au ==================================================================================================================