pam_mount crashes SDDM because helper doesn't close session after authentication

[droserasprout]

Enabled with pam-auth-update pam_mount.so module prevents SDDM 0.13 from starting, see only black screen. Bug reproduces on 16.04 and 16.10 (obviously, they both have SDDM 0.13 in repos). Fixed in upstream, see links below.

bug-report (upsream):
https://github.com/sddm/sddm/issues/637

fixing commit:
https://github.com/sddm/sddm/commit/057b8ba514310e3f5535ea04f6b0e55dffb05209

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

This also gets a listing in the SDDM Release-Notes of Version 0.14.0 [1]

pls. see Changelog-listing:

 "helper: Close session after authentication" (Pier Luigi Fiorini (43))

[1] https://github.com/sddm/sddm/wiki/0.14.0-Release-Announcement

<OT>

Honestly spoken 0.14.0 should be backported into Xenial LTS (my opinion).

<OT>

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

@ droserasprout: FYI linked your bug-report in [request upgrade-software-version] bug #1627340

[Simon Quigley (tsimonq2)]

I'll see if I can backport this fix.

[Simon Quigley (tsimonq2)]

I have uploaded a fix to ppa:tsimonq2/sddm-fixes for Xenial, Yakkety, and Zesty. If this fixes it, then it can be uploaded to Zesty and we can follow the SRU process from there for Xenial and Yakkety.

[droserasprout (droserasprout)]

@tsimonq2 thanks for your work. I've tried to use your fixes but SDDM still shows blank screen when pam_mount is enabled. Last log strings:
[PAM] Starting...
[PAM] Authenticating...
[PAM] returning.
I can provide some additional info you'll request.

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

@ dreosasprout: May be the relevant last lines of /var/log/sddm.log ?

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

Also check: systemctl status sddm.service

and return results,pls.

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

Also check:

loginctl show-session $XDG_SESSION_ID

It turns out then, that there is no relation for you having a black screen (aka stuck SDDM); I do not know enough about your installation/Hardware to help you out on that. But the two previous questions and that one could help to get shine some light into the problem.

I'd suggest that you remove the packages, since they are an early preview, and not yet thoroughfully enough tested:

sudo apt-get install ppa-purge
sudo ppa-purge ppa:tsimonq2/sddm-fixes

(tested that too-it works)

You'll be getting the update once it's through the SRU-bugfix-process of thouroughful testing.

@ Simon: I've made a test install of the packages on two unvirginic production-systems (64-Bit/no external monitors). It doesn't hurt the system. But I discovered a small oops, that may as well come through the backports-ppa, nothing harmfull (kwallet4) but just not nice. But that should get fixed in the ppa. In terms of Zesty I wouldn't want to 'til Apr. to have this srued – and I'd really exspect sddm-0.14 to be in there by then.

In short: if you need assistance on testing that for SRU, I'll set up a juvenile small Virtual-Box installation, upgrade it to represent the current state of packages. As test-pattern I would also suggest to switch to Light-DM and vice-versa. I'll be with you on the other bug-report, then.

[droserasprout (droserasprout)]

@ ellisistfroh, logs are in attachment, take a look please. SDDM works fine without pam_mount module so I guess problem is not in my configuration.

[Flames_in_Paradise (ellisistfroh-deactivatedaccount)]

What is

apt-cache policy pam-kwallet*

on that machine?

[Simon Quigley (tsimonq2)]

This will get fixed once 0.14 is uploaded.

[gelin (dnelubin)]

KDE Neon has sddm 0.14.0 (0.14.0-1~2.gbpf70012+16.04+xenial+build8), however, the issue is reproduced when pam_mount tries to mount LUKS partitions (so the password is required).
Bind mounts works well.

[ITEAS (info-tux-pc)]

Problem exists also with NFSmounts on Kubuntu 18.04

[pterrien (pterrien)]

Hi,
I think this bug still occurs, at least on Debian testing (buster) with sddm 0.18.
I posted an analysis and a workaround on the following github issue, although already closed: https://github.com/sddm/sddm/issues/637#issuecomment-453838344

tl;dr:
There is an issue in /etc/pam.d/sddm-greeter, that calls pam_mount through '@include common-session'.
pam_mount will surely fail, as it is called for the local user sddm, which has probably no access right to the given shared volume.

What is not normal, maybe, is that sddm will then catch a SIGTERM and so will terminate.
The same kind of pam_mount failures occurs with /etc/pam.d/login (eg with user root), and login can proceed correctly.
Why is this a blocking issue when processed by /etc/pam.d/sddm-greeter?

I could imagine the following solutions:
  - modify the /etc/pam.d/sddm-greeter file, either by:
    - replacing the '@include common-session' statement by the actual directives in /etc/pam.d/common-session, EXCEPT the one with pam_mount. This is the workaround proposed by another user on github. It works, but I don't find it very clean, to be honest.
    - replacing the '@include common-session' statement with a substack, with some conditions? I'm not an expert with PAM, I don't know if this is even feasible?
  - do not terminate on a SIGTERM send by pam_mount? Is it feasible, too?
  - apply the workaround I propose: use the pam_mount extended user control features, to exclude the sddm user from trying to mount the volume. We can explicitly exclude this user, or a whole range (all local users for example).

Hope you will find this useful !

Cheers

[ITEAS (info-tux-pc)]

Fixed, with an exclude option:

...
<volume fstype="cifs" server="storage.tux.local" options="vers=3.0" path="iso-images" mountpoint="~/iso-images"> <not><user>root</user></not> <not><user>sddm</user></not> </volume>
...