0

I have a new install of Kubuntu 18.04.1, with user authentication via sssd to the company's Microsoft Active Directory.

Every user has a Samba share on //fileserver6/$USER and I want to mount it at login time.

I managed to get pam_mount configured to mount the share whenever the user logs in, and it was working fine... until I logged out of KDE, and discovered that the sddm-greeter didn't work!

Instead of a login prompt, there's just a black screen with a mouse pointer. In the below pam_mount.conf.xml, I can comment out the <volume> tag, and log in via sddm, then I can uncomment it and log into a terminal session, and the directory is automounted. But I can't have both!

Failing a solution to the problem, I'll happily install another display manager if it works (lightdm won't even let me choose a user). [ETA: lxdm does work]

/etc/security/pam_mount.conf.xml

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
<!--
    See pam_mount.conf(5) for a description.
-->

<pam_mount>

        <!-- debug should come before everything else,
        since this file is still processed in a single pass
        from top-to-bottom -->

<debug enable="0" />

        <!-- Volume definitions -->
<volume user="*" fstype="cifs" server="fileserver6" path="%(USER)" 
        mountpoint="/media/%(USER)/p" options="cruid=%(USER),sec=krb5" />

        <!-- pam_mount parameters: General tunables -->

<luserconf name=".pam_mount.conf.xml" />

<!-- Note that commenting out mntoptions will give you the defaults.
     You will need to explicitly initialize it with the empty string
     to reset the defaults to nothing. -->
<mntoptions allow="nosuid,nodev,loop,encryption,fsck,nonempty,allow_root,allow_other" />
<!--
<mntoptions deny="suid,dev" />
<mntoptions allow="*" />
<mntoptions deny="*" />
-->
<mntoptions require="nosuid,nodev" />

<!-- requires ofl from hxtools to be present -->
<logout wait="0" hup="no" term="no" kill="no" />


        <!-- pam_mount parameters: Volume-related -->

<mkmountpoint enable="1" remove="true" />

</pam_mount>

/etc/pam.d/sddm

auth    requisite       pam_nologin.so
auth    required        pam_succeed_if.so user != root quiet_success

@include common-auth
-auth   optional        pam_gnome_keyring.so
-auth   optional        pam_kwallet.so
-auth   optional        pam_kwallet5.so

@include common-account

session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session optional        pam_keyinit.so force revoke
session required        pam_limits.so
session required        pam_loginuid.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
-session optional       pam_gnome_keyring.so auto_start
-session optional       pam_kwallet.so auto_start
-session optional       pam_kwallet5.so auto_start

@include common-password
session required        pam_env.so
session required        pam_env.so envfile=/etc/default/locale

/etc/pam.d/sddm-greeter

auth    required        pam_permit.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session optional        pam_keyinit.so force revoke
session required        pam_limits.so
session required        pam_loginuid.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open

password        required pam_deny.so
session required        pam_env.so
session required        pam_env.so envfile=/etc/default/locale

/etc/pam.d/common-session

session [default=1]                     pam_permit.so
session requisite                       pam_deny.so
session required                        pam_permit.so
session optional                        pam_umask.so
session required        pam_unix.so 
session optional                        pam_sss.so 
session optional        pam_mount.so 
session optional        pam_systemd.so 
session optional                        pam_mkhomedir.so 

/etc/pam.d/common-auth

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_sss.so use_first_pass
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional        pam_mount.so 
auth    optional                        pam_cap.so 

/etc/pam.d/common-password

password        requisite                       pam_pwquality.so retry=3
password        [success=2 default=ignore]      pam_unix.so obscure use_authtok try_first_pass sha512
password        sufficient                      pam_sss.so use_authtok
password        requisite                       pam_deny.so
password        required                        pam_permit.so
password        optional        pam_mount.so disable_interactive
password        optional        pam_gnome_keyring.so 
1

I faced a similar issue, too, on a fresh install of debian testing (buster), with sddm 0.18.0-1.

Below is a copy of the message I posted to the sddm github issue: https://github.com/sddm/sddm/issues/637.

tl;dr

Modify the pam_mount config in /etc/security/pam_mount.conf.xmlto use the extended user control, in order to exclude the sddm user from trying to mount the volume:

<volume fstype="cifs" server="fileserver6" path="%(USER)" mountpoint="/media/%(USER)/p" options="cruid=%(USER),sec=krb5">
  <not><user>sddm</user></not>
</volume>

Issue description

symptoms

  • Black screen with a mouse pointer, but no possible interaction (left/right mouse click, keyboard)
  • TTYs are accessible
  • systemctl stop sddm && startxallows me to get a working KDE Plasma environment though

context

  • sddm works correctly until I install pam_mount (libpam-mount for debian), and I add a volume in pam_mount configuration, such as:
<volume fstype="cifs" server="server1.ad.lan" options="domain=MYDOMAIN,vers=3.0" path="data" mountpoint="~/mnt/server1/data" />

To be more precise:

  • with the default pam_mount configuration (ie with no volume), sddm will display correctly
  • adding a volume to the pam_mount config, then systemctl restart sddm will trigger the symptoms described above
  • removing the volume from pam_mount config, then systemctl restart sddm, will make sddm display correctly again

Analysis

logs

In syslog:

Jan 13 15:12:56 mycomputer sddm[2338]: Greeter starting...
Jan 13 15:12:56 mycomputer sddm[2338]: Adding cookie to "/var/run/sddm/{b73b2904-3de9-46d5-b2ac-a407bd3be089}"
Jan 13 15:12:56 mycomputer sddm-helper[2349]: [PAM] Starting...
Jan 13 15:12:56 mycomputer sddm-helper[2349]: [PAM] Authenticating...
Jan 13 15:12:56 mycomputer sddm-helper[2349]: [PAM] returning.
Jan 13 15:12:56 mycomputer sddm[2338]: (pam_mount.c:568): pam_mount 2.16: entering session stage
Jan 13 15:12:56 mycomputer sddm-helper[2349]: [PAM] Preparing to converse...
Jan 13 15:12:56 mycomputer sddm-helper[2349]: [PAM] Conversation with 1 messages
Jan 13 15:22:53 mycomputer sddm[2338]: Signal received: SIGTERM

humble assumptions... to be checked

As stated in github:

Same here. I managed to get this working by commenting out:

@include common-session

and including all the content of common-session except the pam_mount.so line at /etc/pam.d/sddm-greeter, but when users close their sessions pam_mount is unaware so when they logout their mountpoints don't get unmounted.

The issue seems to occur in /etc/pam.d/sddm-greeter , when performing @include common-session:

  • pam_mount tries to mount the volume with the current user, which is sddm, and fails
    • in my case, that is perfectly normal, as the current user is the local sddm one, and it has no access to my AD domain member server

What I don't understand is:

  • when manually logging in with a local user (eg root), ie called by /etc/pam.d/login: this pam_mount failure is ignored, and login can proceed normally
  • when called by /etc/pam.d/sddm-greeter: the sddm process catches a SIGTERM, and terminates

questions / possible solution

Is it possible for the sddm process to silently ignore errors that occur in /etc/pam.d/common-session? Otherwise, is it possible to modify /etc/pam.d/sddm-greeter, by using conditions in substackinstead of a simple @include?
Sorry, I'm no expert with pam, I don't know if this makes sense...

Otherwise, in addition to above proposal, below is another possible workaround:

Other workaround: modify your pam_mount configuration

As stated before, the issue seems to occur because pam_mount tries to mount a share using the sddmuser, which has no credentials for it.

So, basically, we just have to exclude the sddm user (and others, if needed), from mounting the share. This uses the extended user control features in pam_mount (link).

So, instead of defining the volume as below in /etc/security/pam_mount.conf.xml:

<volume fstype="cifs" server="server1.ad.lan" options="domain=MYDOMAIN,vers=3.0" path="data" mountpoint="~/mnt/server1/data" />

We can write (3 variants, adapt to your needs):

Variant 1: allow only a given range of UIDs

<volume fstype="cifs" server="server1.ad.lan" options="domain=MYDOMAIN,vers=3.0" path="data" mountpoint="~/mnt/server1/data" uid="5000-999999999" />

Variant 2: exclude a given range of UIDs

<volume fstype="cifs" server="server1.ad.lan" options="domain=MYDOMAIN,vers=3.0" path="data" mountpoint="~/mnt/server1/data">
  <not><uid>0-4999</uid></not>
</volume>

Variant 3: exclude the sddm user only

<volume fstype="cifs" server="server1.ad.lan" options="domain=MYDOMAIN,vers=3.0" path="data" mountpoint="~/mnt/server1/data">
  <not><user>sddm</user></not>
</volume>

Conclusion

Sorry for this long post, I hope you will find it useful!

Cheers.

6
  • Other possible solution: define volumes per user, in ~/.pam_mount.conf.xml instead of /etc/security/pam_mount.conf.xml. This way you will completely bypass the sddm stuff. But I don't know if this is applicable in your situation? – pterrien Jan 13 '19 at 16:02
  • Thanks much for that. At the moment, the users are me... So, it would be no problem to define volumes per user. But I want to roll this out company-wide, to mount all our standard Windows shares, so I think your Variant 2 is probably the way to go (because not every Linux user is an SDDM user, but LightDM has the same issue). I'll check this out ASAP. – Auspex Jan 14 '19 at 16:09
  • btw, I wouldn't call this a long post; just a thorough one. – Auspex Jan 14 '19 at 16:12
  • Unfortunately, I'm not seeing any errors in the log, but still getting the black screen with sddm. :-( – Auspex Jan 21 '19 at 11:41
  • Strange... can you confirm you tested all bullet points in part Issue description (both symptoms and context)? Maybe you can also try to extend the exclusion range (e.g. users 0-999999999), to check if the issue comes from the extended user control tag, or the volume definition itself? – pterrien Jan 23 '19 at 0:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.