How to configure user private groups on arch linux

mphi · 2022-09-17 15:49:02

Hi,

I'm trying to allow collaboration of multiple users in a shared directory based on common group membership. In Debian this is called User Private Groups: https://wiki.debian.org/UserPrivateGroups. Besides setting the permissions on the shared directory, this requires to globally set the umask to 002 for all users.

According to https://wiki.archlinux.org/title/Umask this should be done in /etc/profile. This works fine for the text console (Ctrl+Alt+F2) but not for the KDE plasma desktop environment.

Apparently this is due to KDE being started via systemd --user. According to https://unix.stackexchange.com/a/379329 umask can be set via pam_umask on current systemd versions.
I added the following line to /etc/pam.d/login:

session    optional     pam_umask.so usergroups

But running umask in konsole on KDE plasma still returns 0022.

How can I set umask to 002 for all users on KDE plasma?

Regards,
Matthias

Lone_Wolf · 2022-09-18 11:28:15

pam_umask.so can be overwritten.

archwiki on umask wrote:

to change your umask during your current session only, simply run umask and type your desired value.

Have you checked if setting umask temporarily works as intended ?

mphi wrote:

Apparently this is due to KDE being started via systemd --user

archwiki mentions 2 methods to start kde/plasma : using a display manager or from console .
Both use the startplasma-x11 or startplasma-wayland executables which as far as I know don't need systemctl --user.

How are you starting kde ?

Welcome to archlinux forums.

mphi · 2022-09-19 05:14:54

Thank you for your reply.

Have you checked if setting umask temporarily works as intended ?

Yes, setting umask 002 in konsole has the desired effect.

How are you starting kde ?

KDE is started by SDDM.

$ pstree -Tapu
systemd,1
[..]
  ├─sddm,476
  │   ├─Xorg,543 -nolisten tcp -background none -seat seat0 vt1 -auth /var/run/sddm/{f537d98b-285a-4b7f-bf84-46942f96a511} -noreset -displayfd 17
  │   └─sddm-helper,773 --socket /tmp/sddm-auth118a87d0-b1dd-4b41-8a75-d4fdad57037a --id 1 --start /usr/bin/startplasma-x11 --user mphi
  │       └─startplasma-x11,783,mphi
  ├─systemd,775,mphi --user
[..]
  │   ├─ksmserver,820
  │   │   ├─konsole,909 -session 10d8e47865000162080233600000053810010_1663562382_24222
[..]
  │   ├─kwin_x11,821 --replace
  │   ├─plasmashell,844 --no-respawn
  │   │   ├─dolphin,2711

pam_umask.so can be overwritten.

Do you have any idea how to determine who is overwriting it?

Lone_Wolf · 2022-09-19 10:23:24

Now I understand why you thought kde was started using systemd user .
systemctl status --user output should help to clarify what is started through systemd --user .

Do you have any idea how to determine who is overwriting it?

/etc/profile is the typical suspect and where archlinux sets the default umask .

Do you want to change umask for all users of this system or only for some ?
If the latter, setting umask per user in ~/.bashrc (or ~/.zshrc or whatever file is read by their login shell) would be an alternative .

mphi · 2022-09-19 11:44:18

systemctl status --user output should help to clarify what is started through systemd --user .

systemctl status --user also shows the KDE applications. Notably konsole and dolphin, who are used to create new files.

           ├─app.slice
[..]
           │ ├─app-org.kde.dolphin-c258d128e88e4ec99e001b2f7fcc0490.scope
           │ │ └─2711 /usr/bin/dolphin
           │ ├─app-org.kde.konsole-5c1e1bfcfed04879bba6823287b37da1.scope
           │ │ ├─  909 /usr/bin/konsole -session 10d8e47865000162080233600000053810010_1663562382_24222
           │ │ ├─  939 /bin/bash
           └─session.slice
             ├─dbus.service
             │ ├─788 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
             │ └─977 /usr/bin/kwalletd5
             ├─gvfs-daemon.service
             │ ├─1089 /usr/lib/gvfsd
             │ └─1094 /usr/lib/gvfsd-fuse /run/user/1000/gvfs -f
             ├─plasma-kded.service
             │ └─819 /usr/bin/kded5
             ├─plasma-ksmserver.service
             │ └─820 /usr/bin/ksmserver
             ├─plasma-kwin_x11.service
             │ └─821 /usr/bin/kwin_x11 --replace
             ├─plasma-plasmashell.service
             │ └─844 /usr/bin/plasmashell --no-respawn
             └─pulseaudio.service
               ├─ 997 /usr/bin/pulseaudio --daemonize=no --log-target=journal
               └─1032 /usr/lib/pulse/gsettings-helper

/etc/profile is the typical suspect and where archlinux sets the default umask .

That's where I do set umask. But the setting only has effect for console sessions but not for GUI sessions started through SDDM.

Do you want to change umask for all users of this system or only for some ?

I want change umask for all users of this system.

Lone_Wolf · 2022-09-19 11:58:47

picture is getting clearer, let's check if sddm / display manager is part of the issue .

append systemd.unit=multi-user.target to your bootloader command to ensure you boot to a console instead of gui
(this will also prevent sddm from being started)

login as normal user, check umask .

configure .xinit to start kde , then run startx .

check if umask has changed / systemd --user status .

Some links for details / background info
https://wiki.archlinux.org/title/System … _boot_into
https://wiki.archlinux.org/title/Xinit
https://wiki.archlinux.org/title/KDE#From_the_console

Last edited by Lone_Wolf (2022-09-19 12:00:14)

mphi · 2022-09-19 14:47:09

With startx instead of SDDM the behavior is the same. umask is correct on the text console but not in KDE. KDE / plasma is also running via systemd --user when started via startx.

The problem does not seem to be that KDE is started via systemd --user. This seems to be the default behavior on current systems.

So the question is rather why neither umask from /etc/profile nor the setting from pam_umask.so are honoured by systemd --user?

Lone_Wolf · 2022-09-20 10:38:43

Blaming systemd for something is easy (and way to often correct), but in this case I don't think it is at fault .

A search for kde + umask lead me to https://unix.stackexchange.com/question … ansactions .

It has similarrities to your issue and shows 2 potential causes worth investigating.

- /etc/login.defs has an umask entry.

man login.defs section UMASK wrote:

It is also used by login to define users' initial umask.

That would explain how it can override the value in /etc/profile .
/etc/login.defs comes with the shadow package and is created by arch devs, not upstream.
I suggest you compare it with the login.defs used on the debian install .

Incase that doesn't solve the issue, the 2nd cause worth investigating is :
- the mount options of the shared folder are incorrect / don't do what is desired.

Edit:
I just realised that the stackexchange link in post #1 also mentions login.defs in atleast two of the answers

Last edited by Lone_Wolf (2022-09-20 10:46:04)

seth · 2022-09-20 14:30:55

Yeah… we'll still just blame lennart.
https://github.com/systemd/systemd/issues/6077
https://github.com/systemd/systemd/issues/16963

And recently https://groups.google.com/g/linux.debia … 6rIHdbVGAQ

You can probably mitigate it:
https://github.com/systemd/systemd/pull … 533d2ec663
https://man.archlinux.org/man/core/syst … .exec.5.en

UMask=
Controls the file mode creation mask. Takes an access mode in octal notation. See umask(2) for details. Defaults to 0022 for system units. For user units the default value is inherited from the per-user service manager (whose default is in turn inherited from the system service manager, and thus typically also is 0022 — unless overridden by a PAM module). In order to change the per-user mask for all user services, consider setting the UMask= setting of the user's user@.service system service instance. The per-user umask may also be set via the umask field of a user's JSON User Record[5] (for users managed by systemd-homed.service(8) this field may be controlled via homectl --umask=). It may also be set via a PAM module, such as pam_umask(8).

There may also be a chance that the KDE service does something like that (still lennarts fault for introducing this mess), but grepping plasma-workspace for umask didn't bring up anything.
So lennarts fault until proven false.

mphi · 2022-09-20 16:02:41

https://github.com/systemd/systemd/issues/6077

I saw this issue and it looks pretty much like what I am experiencing. But this issue is from 2017 and should be fixed in current systemd 251.

The documentation quoted by seth explicitly states unless overridden by a PAM module. So why does pam_umask.so not work?

The following method actually works for me: sudo systemctl edit user@.service

[Service]
UMask=0002

But I rather consider this a workaround at the moment. I would prefer one single place to set umask for KDE and text console.

I will look into the /etc/login.defs mentioned by Lone_Wolf and again into pam_umask.so.

seth · 2022-09-20 16:13:39

But this issue is from 2017

I listed them to show a pattern in order to make a point to get to the conclusion that it's lennart's fault
The more recent debian bug suggests that this or sth. like this might have creeped up again.

For pam_umask, what's the output of

id

and did you try "umask=002" as parameter?

mphi · 2022-09-21 09:58:07

The output of id is as follows:

uid=1000(mphi) gid=1000(mphi) groups=1000(mphi),108(vboxusers),150(wireshark),970(docker),987(uucp),993(input),998(wheel)

I commented the umask line in /etc/profile and tried various pam_umask settings in /etc/pam.d/login:

                     | Console umask | KDE umask
---------------------+---------------+-----------
no pam_umask         |          0022 |      0022
pam_umask usergroups |          0007 |      0022
pam_umask umask=002  |          0002 |      0022

So pam_umask seems to be working, but not for KDE. Maybe /etc/pam.d/login is not the correct place for sessions started via SDDM / systemd --user?

mphi · 2022-09-21 14:03:19

Maybe /etc/pam.d/login is not the correct place for sessions started via SDDM / systemd --user?

That was it! pam_umask.so needs to be configured in a file that is included by both, /etc/pam.d/login and /etc/pam.d/systemd-user, which is /etc/pam.d/system-login.

The solution is to add the following line to /etc/pam.d/system-login

session    optional   pam_umask.so         usergroups

This works for both, console sessions and KDE. There is no need to set umask in /etc/profile or override the systemd user@.service.
Should we document this in the arch wiki?

seth · 2022-09-21 14:10:56

Did you try to start eg. openbox via SDDM and check the umask?
Either the pam doesn't make it to SDDM (not in the include chain) or this would be a bug in systemd:

Last edited by seth (2022-09-21 14:53:31)

Lone_Wolf · 2022-09-22 09:53:49

mphi wrote:

Should we document this in the arch wiki?

The umask page seems to be the only place in the wiki where pam_umask.so is mentioned, I do think it would be a good idea to add something about this.

mphi · 2022-09-26 06:10:45

Lone_Wolf wrote:

I do think it would be a good idea to add something about this.

Done: https://wiki.archlinux.org/title/Umask# … E_/_Plasma
A review would be appreciated.

Lone_Wolf · 2022-09-26 11:09:20

I'd make this more about umask & systemd-user and mention kde/plasma in the body.

Arch Linux

#1 2022-09-17 15:49:02

How to configure user private groups on arch linux

#2 2022-09-18 11:28:15

Re: How to configure user private groups on arch linux

#3 2022-09-19 05:14:54

Re: How to configure user private groups on arch linux

#4 2022-09-19 10:23:24

Re: How to configure user private groups on arch linux

#5 2022-09-19 11:44:18

Re: How to configure user private groups on arch linux

#6 2022-09-19 11:58:47

Re: How to configure user private groups on arch linux

#7 2022-09-19 14:47:09

Re: How to configure user private groups on arch linux

#8 2022-09-20 10:38:43

Re: How to configure user private groups on arch linux

#9 2022-09-20 14:30:55

Re: How to configure user private groups on arch linux

#10 2022-09-20 16:02:41

Re: How to configure user private groups on arch linux

#11 2022-09-20 16:13:39

Re: How to configure user private groups on arch linux

#12 2022-09-21 09:58:07

Re: How to configure user private groups on arch linux

#13 2022-09-21 14:03:19

Re: How to configure user private groups on arch linux

#14 2022-09-21 14:10:56

Re: How to configure user private groups on arch linux

#15 2022-09-22 09:53:49

Re: How to configure user private groups on arch linux

#16 2022-09-26 06:10:45

Re: How to configure user private groups on arch linux

#17 2022-09-26 11:09:20

Re: How to configure user private groups on arch linux

Board footer