useradd - adjust defaults to other tools and distributions?
Hi, After the discussion the last days about creating users and the defaults used for it, I looked at our defaults and where we deriviate from upstream, other Linux distributions and other tools we use already today. We change explicit: USERGROUPS_ENAB from "yes" to "no". All other tools we provide and other distros do create usergroups by default, so I suggest to change it back to "USERGROUPS_ENAB yes". CREATE_HOME from "yes" to "no". I did never understand why we disabled this. All other tools we provide and other distros create the home directory by default. I would suggest to change that back to "yes". FORCE_SHADOW from "yes" to "no". I also don't understand this change. We should revert that change, so we don't need the hacks in other places to split passwd later during installation. If we enforce the shadow usage later, why not from the beginning? HOME_MODE not set We should set "HOME_MODE 0700" as other distros do. Any comments? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Hi Thorsten, Thorsten Kukuk <kukuk@suse.de> writes:
No objections from my side as this reduces complexity and (imho) pointless differences to other distros. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On Thu, Aug 5, 2021 at 3:18 PM Thorsten Kukuk <kukuk@suse.de> wrote:
It didn't bother me but I also wondered why we have those changes. I agree with Thorsten's proposed changes unless there are good reasons explaining the settings the way they are. Cheers, Maurizio -- Maurizio Galli (m4u)
On Thu, Aug 5, 2021 at 5:37 AM Maurizio Galli <mauriziogalli@opensuse.org> wrote:
Could we also change SUSE distributions to configure subuid and subgid by default like Fedora does? Then rootless podman would just work out of the box. I struggled to get this working for a talk of mine a while back, and it'd be nice to not have to suffer in the future... -- 真実はいつも一つ!/ Always, there's only one truth!
On Thu, Aug 05, Neal Gompa wrote:
useradd does this for me out of the box on SLES and openSUSE. The YaST users module does not do it, but I heard that this got "fixed" some weeks ago by using now useradd directly. Haven't verified that yet, I don't have a system with YaST installed... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Hi, Am Donnerstag, 5. August 2021, 12:05:59 CEST schrieb Thorsten Kukuk:
Yes, this got fixed: https://bugzilla.suse.com/show_bug.cgi?id=1185342 Cheers, Fabian
Thorsten
On Thu, Aug 05, Maurizio Galli wrote:
It didn't bother me but I also wondered why we have those changes.
Parts of this changes go back before I started at SUSE... I doubt that there is anybody today anymore who knows why this changes were done. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Thu, 5 Aug 2021 09:18:45 +0200, Thorsten Kukuk <kukuk@suse.de> wrote:
+1 from me on all
Thorsten
-- H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
Hello, Am Donnerstag, 5. August 2021, 09:18:45 CEST schrieb Thorsten Kukuk:
In case someone wonders what the config options do, see man login.defs and/or the comments in /usr/etc/login.defs.
Makes sense.
Also makes sense.
Agreed. Sidenote:This option is not documented in man login.defs - worth a bugreport?
HOME_MODE not set We should set "HOME_MODE 0700" as other distros do.
I'm not sure about that because - it breaks ACLs (which will become "effective ---" AFAIK) - it breaks ~/public_html Since you also propose to create a group for each user, we could use 0710 or 0750. This would technically not add any permissions (unless you add another user to your $USERNAME group), but it would give us working ACLs. Working ACLs would allow to add exceptions that could help with ~/public_html. (Not sure if we should create an ACL for wwwrun to be able to reach ~/public_html by default, but that's a discussion for bonus points anyway ;-) I also wonder if we should make UMASK more restrictive - maybe 0027 instead of the current 0022? Regards, Christian Boltz --
On Thu, Aug 05, Christian Boltz wrote:
If you use ACLs you have of course adjust the permissions of the directories, too. If you don't use ACLs for the main home directory already.
- it breaks ~/public_html
It does not break existing ~/public_html configurations. It does not break default apache confiurations. It requires one step more to enable it, which is Ok. We don't support ~/public_html out of the box. This is something the admin has to configure anyways, and if the user wants to use ~/public_html, he has to create that directory, too. So it's just one step more to adjust the permissions.
That's the default everywhere and 0027 has more impact on breaking things than 700 for the home directory. Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On 05/08/2021 15.02, Thorsten Kukuk wrote:
On Thu, Aug 05, Christian Boltz wrote:
I have several users that were created by YaST over the years, and all seem to have the ~/public_html, which I did not create myself. Maybe now it is not created, but certainly in the past it was. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
On Monday, 9 August 2021 8:03:54 PM ACST Carlos E. R. wrote:
Ugh. I really don't want a "public_html" folder in my home folder - that's what /srv/www is for...with appropriate permissions and/or acl's, of course. ~ is for my stuff, not public stuff. I guess that's part of the beauty of Linux - anyone is free to configure (and break) it however they want. :) -- ================================================================================================================== Rodney Baker rodney.baker@iinet.net.au ==================================================================================================================
On Mon, 9 Aug 2021 12:33:54 +0200 Carlos E. R. wrote:
Up to Leap 42.3 it was part of the desktop-data-openSUSE RPM used as skeleton for the creation of home directories: $ rpm -qf /etc/skel/public_html/ desktop-data-openSUSE-42.1-4.5.noarch $ rpm -qi desktop-data-openSUSE Name : desktop-data-openSUSE Version : 42.1 Release : 4.5 Architecture: noarch Install Date: So 21 Mai 2017 15:28:29 CEST Group : System/GUI/Other Size : 514753 License : GPL-2.0+ Signature : RSA/SHA256, Do 18 Mai 2017 00:02:00 CEST, Key ID b88b2fd43dbdc284 Source RPM : desktop-data-openSUSE-42.1-4.5.src.rpm Build Date : Do 18 Mai 2017 00:01:24 CEST Build Host : lamb06 Relocations : (not relocatable) Packager : http://bugs.opensuse.org Vendor : openSUSE Summary : Shared Desktop Files for openSUSE Leap Description : This package contains shared desktop files, like the default applications menu structure and the default wallpaper. Distribution: openSUSE Leap 42.3 Regards, Dieter
Thorsten Kukuk wrote:
The reasons for that seem pretty archaic and user private groups are normally accompanied with umask 002. This is explained eg here: https://lists.debian.org/debian-devel/2010/05/msg00315.html As stated there without the umask change it's kind of pointless though. If we also wanted to change the umask we'd have to be sure pam_umask etc is set up correctly to avoid upgrade situations where existing users with shared group end up having umask 002. Not sure how common setgid project directories are anymore anyway. The use case for RH adding that feature into shadow >20 years ago (RCS?) might have vanished. If so, we survived the times where that might have been important. So could just as well not bother and stay with our shared users group now. cu Ludwig PS: AFAICT shadow-utils version 19990827 introduced USERGROUPS_ENAB and the guy doing the package update back then apparently decided to turn it off and keep the previous behavior of SUSE Linux. Check the changelog of an old SUSE Linux before the time when the previous shadow package was dropped. :-) -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Thu, Aug 05, Ludwig Nussel wrote:
I completly disagree that you need a umask 002 if you have a private group. Many wrote here already that they prefer a "private" group and then let the admin add selected users, who should be able to access the files. In this case you don't want that they can access and edit everything in your home, but only what you give free. So private group and default umask of 022 doesn't seem to conflict for me. But this would be a good reason for private groups and umask 002: https://lists.debian.org/debian-devel/2010/05/msg00254.html But it requires devel groups and not, as some discussed here, addition of additional users to the private group. Since we cannot change the past, I still think the best is to use private groups, keep umask 022 (or existing users get a security problem) and if people use UPG and devel groups, they can set UMASK in their login profile to 002. That's what RedHat is doing, too. Which also means, the claim in the debian thread, that RedHat is using umask 002 is wrong. For security and collaboration reasons, I really like the UPG idea with devel groups best, even if this means that this users have to set their own UMASK. Thorsten
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Thorsten Kukuk wrote:
Just different words for the same reasoning.
Well, they do something funny https://pagure.io/setup/blob/master/f/bashrc#_68 ie login shells have 022 while non-login shells have 002. 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. Makes more sense to me but I guess Fedora has reasons too. Curious what the reasons are. 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. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Mon, Aug 09, Ludwig Nussel wrote:
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.
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 -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Thorsten Kukuk wrote:
The link I posted showed if [ $UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then umask 002 [...] pam_umask has a similar safeguard: https://github.com/linux-pam/linux-pam/blob/master/modules/pam_umask/pam_uma... cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Mon, Aug 09, Ludwig Nussel wrote:
Thorsten Kukuk wrote:
Which always overwrites the umask the admin did configure, if we enable the usergroups option of pam_umask. So not a real working solution. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Monday, 9 August 2021 7:00:59 PM ACST Thorsten Kukuk wrote:
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 ==================================================================================================================
On Thursday 2021-08-05 15:05, Ludwig Nussel wrote: [https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/...]
The upstream changelog of shadow 19990827 has this to say: - added support for "usergroups" feature often found in Linux distributions (if USERGROUPS_ENAB in login.defs set to "yes", uid != 0, uid == gid, and username == groupname, then set umask to 002 instead of 022) What "Linux distributions"? One can find USERGROUPS logic as early as Debian 0.93r6 adduser 1.94 (1995-10-09). This was at a time when Debian did not even use the shadow mechanism, with passwords being still in the second field of /etc/passwd. Not to mention _RH's_ shadow code, which I think they only jumped on with shadow-4.x, which is modern day age (2007+) by comparison. Ironically, Debian never did set the setgid bit on the user's homedir (bug?), but it was present on /home (bug #2?). # ls -al /home total 3 drwxrwsr-x 3 root staff 1024 Dec 13 13:21 . drwxr-xr-x 18 root root 1024 Dec 13 13:18 .. drwxr-xr-x 2 user user 1024 Dec 13 13:21 user setgid project directories are kinda unnecessary since filesystem ACLs were added. usergroups logic should preferably be disabled by default at the root (in other words, in the RH shadow that exists today).
On Mon, Dec 13, Jan Engelhardt wrote:
Using USERGROUPS_ENAB: is there any Linux distribution except openSUSE/SUSE not doing it? But about modifying the umask value: only Ubuntu (Debian? I don't know) is doing that. It's at least a Ubuntu specific patch. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
On Monday 2021-12-13 15:50, Thorsten Kukuk wrote:
Not just Linux.. FreeBSD "adduser" command: usergroups behavior, apparently since 1995-03-08. OpenBSD has the same adduser source. Solaris/OmniOS/OpenIndiana "useradd": no usergroups. UnixWare 7.1 useradd: no usergroups. Haiku r1alpha2 (2010): no usergroups. busybox's "adduser": usergroups behavior, doing so since 2010. It's actually the only implementation I have seen to sets the sgid bit. Slackware 12.0 (2007) "adduser": no usergroups Slackware 12.0 "useradd" (shadow-4.0.3): no usergroups _despite_ USERGROUPS_ENAB yes being set in login.defs. Slackware 14.2 "useradd" (shadow-4.2.1): usergroups behavior RedHat Linux 2 & RHL5 (shadow-980403) useradd: usergroups behavior. It's actually the only implementation I have seen to use mode 0700. Caldera OpenLinux 3.1 (2001): like slackware 12.0 I found it to be fair to look at what now seem to be historic versions, before shadow propagated usergroups onto everyone.
Hi, one more comment... On Thu, Aug 05, Thorsten Kukuk wrote:
While the configuration file creates the impression that there is a default "yes", this is not true: There is no configuration default, only an "implementation" default. As result, Fedora/RedHat will create the home directory and Debian/Ubuntu will not... As everybody who answered was in favour of changing this to "yes", I still would like to change it, so that the home directory will always be created by default. I don't see any sense to create an user without home directory. This is only for normal users, this variable is ignored for system users! So system users would still be created without home directory. Comments? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Fri, Aug 13, Joachim Wagner wrote:
No, this would be "useradd -M ...". Beside that re-creating an user account does not mean your user will get the same UID again and can access the old home directory. And the password is also gone. In this case, I would save the old user account and re-apply it to /etc/passwd, /etc/group and /etc/shadow. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
participants (16)
-
Bernhard M. Wiedemann
-
Carlos E. R.
-
Christian Boltz
-
Dan Čermák
-
dieter
-
Eric Schirra
-
Fabian Vogt
-
Gerald Pfeifer
-
H.Merijn Brand
-
Jan Engelhardt
-
Joachim Wagner
-
Ludwig Nussel
-
Maurizio Galli
-
Neal Gompa
-
Rodney Baker
-
Thorsten Kukuk