Hi Thorsten, Thorsten Kukuk writes:

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?

No objections from my side as this reduces complexity and (imho) pointless differences to other distros. Cheers, Dan -- Dan Čermák 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 5:37 AM Maurizio Galli wrote:

On Thu, Aug 5, 2021 at 3:18 PM Thorsten Kukuk wrote:

...

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?

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.

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:

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...

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)

On Thu, 5 Aug 2021 09:18:45 +0200, Thorsten Kukuk wrote:

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?

+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

On Thu, Aug 05, Christian Boltz wrote:

...

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)

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.

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?

That's the default everywhere and 0027 has more impact on breaking things than 700 for the home directory. Thorsten

Regards,

Christian Boltz --

...

Das hatte ich (samt Kommentar aus der /etc/postfix/transport) doch schon in meiner letzten Mail erklärt ... ;) Sandy ist schuld ;-) Erst mit seiner Erklärung ist mir aufgefallen, dass ich es nicht verstanden habe. [> David Haller und Peter Mc Donough in opensuse-de]

-- 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 14.49, Christian Boltz wrote:

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.

I also think, 0750 is a good idea. In the default config, it is as secure as HOME_MODE 0700 but if you want to share files with other users and add them to your group, it will just work.

Thorsten Kukuk wrote:

On Thu, Aug 05, Ludwig Nussel wrote:

...

Thorsten Kukuk wrote:

...

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".

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.

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

Just different words for the same reasoning.

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.

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)

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.

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 Monday, 9 August 2021 8:03:54 PM ACST Carlos E. R. wrote:

On 05/08/2021 15.02, Thorsten Kukuk wrote:

...

On Thu, Aug 05, Christian Boltz wrote:

...

- 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.

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.

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:

...

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.

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.

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

Hi, one more comment... On Thu, Aug 05, Thorsten Kukuk wrote:

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".

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)

...

[...] I don't see any sense to create an user without home directory.

This (creating a user without a home directory by default) has been puzzling me, too, so personally I support your proposal.

I assumed this is for a fresh OS install keeping an old home filesystem. I never tried this though as I prefer to decide for each hidden configuration file and folder whether to keep it. Joachim

On Thursday 2021-08-05 15:05, Ludwig Nussel wrote: [https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/...]

Thorsten Kukuk wrote:

...

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".

The reasons for that seem pretty archaic and user private groups are normally accompanied with 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. ... PS: AFAICT shadow-utils version 19990827 introduced USERGROUPS_ENAB and

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 Monday 2021-12-13 15:50, Thorsten Kukuk wrote:

On Mon, Dec 13, Jan Engelhardt wrote:

...

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"?

Using USERGROUPS_ENAB: is there any Linux distribution except openSUSE/SUSE not doing it?

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.