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!

Hi, Am Donnerstag, 5. August 2021, 12:05:59 CEST schrieb Thorsten Kukuk:

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

Yes, this got fixed: https://bugzilla.suse.com/show_bug.cgi?id=1185342 Cheers, Fabian

Thorsten

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

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

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)

-- 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 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 -- 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 Mon, Aug 09, Ludwig Nussel wrote:

Thorsten Kukuk wrote:

...

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

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

On Fri 2021-08-13, Thorsten Kukuk wrote:

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 (creating a user without a home directory by default) has been puzzling me, too, so personally I support your proposal. Gerald

On Fri, Aug 13, Joachim Wagner wrote:

...

...

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

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)