Hi I've opened issue #1159 on SDDM Github [1], with a patch that makes better use of "initgroups" and "pam_setcreds", I hope.
@Remy Blank if you could try the patch and comment on the issue, that may help SDDM project members to evaluate it. Thanks Best regards Mickaël Bucas [1] https://github.com/sddm/sddm/issues/1159 Le ven. 19 avr. 2019 à 00:34, Mickaël Bucas <mbu...@gmail.com> a écrit : > > Le lun. 15 avr. 2019 à 20:26, Remy Blank <remy.bl...@pobox.com> a écrit : > > > > > After a reboot, the problem disappears for a while, but comes again, > > > and I didn't find what could trigger it. > > > I can't figure what KDE could have to do with user groups returned by > > > the kernel ! > > > > > > Does anyone have a hint on the origin of this problem ? > > > > Yes, this is triggered by restarting the xdm service, possibly limited > > to sddm users. > > > > I have noticed the same issue here. Groups are correct after a reboot, > > but if I do: > > > > $ /etc/init.d/xdm restart > > > > and log into KDE, then I'm a member of all sorts of system groups. I'm > > using sddm, maybe it happens with other login managers as well. > > > > I suspect that this is due to inheriting the supplementary groups of > > which "root" is a member at the time the login manager is started. At > > boot time, it is a member of no additional groups, whereas in a root > > shell, it is: > > > > # groups > > root bin daemon sys adm disk wheel floppy dialout tape video > > > > I suspect this is a bug in sddm, or maybe in pam. It should drop all > > supplementary groups before switching to the user logging in. > > > > As a workaround, I now always reboot instead of restarting xdm. > > > > -- Remy > > Thanks for pointing me to SDDM. After looking at the source code [1] > that prepares the user session I think it's not correct. > The main problem is that it doesn't call "initgroups" when PAM is > enabled. This function is the one that loads the list of local groups > for the user. > PAM functions should be called afterwards to load additional groups > with for example pam_group.so, according to man pam_setcred(3) > > This is confirmed by looking at the code of XDM for the same action, > which calls "initgroups" in all cases [2]. > I found this piece of code interesting with for example : > # if defined(BSD) && (BSD >= 199103) > So it seems it's been around for a really long time ! > > I also found issue 416 on SDDM [3] on Github that seems to be the same > problem, but it has been closed, with a dubious explanation that this > would be caused by KDE kinit. > I don't believe it because KDE processes are launched with the user > session id, and therefore shouldn't be able to add system groups to > the session. > And if I look at the groups of sddm-greeter when it's running under > user "sddm", they are already incorrect before a KDE session is > opened. > mick@xxx ~ $ grep Groups /proc/$(pidof sddm-greeter)/status > Groups: 0 1 2 3 4 6 10 11 26 27 27 243 > > I will try to modify SDDM code to include "initgroups" where I suppose > it should be called. > This could result in a new bug or a pull request depending on the results... > > Best regards > Mickaël Bucas > > [1] https://github.com/sddm/sddm/blob/develop/src/helper/UserSession.cpp > [2] https://gitlab.freedesktop.org/xorg/app/xdm/blob/master/xdm/session.c > [3] https://github.com/sddm/sddm/issues/416
