smbd with "obey pam restrictions" enabled unmounts my interactive users' ecryptfs home directory

[0xC0000022]

I am using KDE (kde-plasma-desktop, not Kubuntu) but I have seen this happening before with GNOME (vanilla-gnome-desktop); I basically switched ... the installation was a 20.04 "server" initially because the desktop installation media would not even boot on my machine. Either way, I am merely mentioning this, but the desktop environment doesn't really matter for this defect.

I have configured my desktop so that within my LAN certain shares can be accessed without user/password restrictions. For convenience I have mapped the guest account to my interactive user. This means files/directories created on the shares in question will automatically be owned by myself.

Alas, every now and then, the ecryptfs home folder gets simply unmounted under my nose, WHILE I am _interactively logged on_ (i.e. in KDE). This happened several times and without a real pattern emerging which would give me clues.

So I set out to track it down and found entries pertaining to smbd which tell me about a session being closed for my interactive user (redacted by substituting johndoe):

===============================================
Sep 08 21:47:20 machine smbd[144802]: pam_unix(samba:session): session closed for user johndoe
===============================================

Upon a closer look it turned out that this was the exact point when the ecryptfs home folder got unmounted (the above is merely exemplary of the issue, but that's already the reproduced occurrence, read on).

Alright, so I saw that pam_unix is involved and smbd is involved. First I suspected that systemd was doing Its Thing™ and killing my processes (I had encountered this with Tmux before to my dismay) but even after setting "KillExcludeUsers=root johndoe" (and, yes, restarting logind) the problem first _seemed_ to have gone away, but it returned again.

Notably there was no message about pam_unix opening a session for my interactive user for smbd. All research I did on how best to log what was going on w.r.t. the session management of smbd/PAM didn't get me any further.

So I entered the trial&error phase of hunting down the root cause.

Basically what I did was in Tmux to edit smb.conf while in another Tmux window having three things running (1 and 3 as root):

1.: while mountpoint /home/johndoe; do service smbd restart; date; sleep 2s ; done
2.: watch 'mount|grep ecryptfs'
3.: tail -F /var/log/auth.log|grep samba:session

Fortunately this almost immediately yielded the desired result. The third time the loop body from 1. ran, the home folder was no longer mounted and the loop quit.

Simultaneously I could see that mount no longer listed the home folder either and the auth.log received that "pam_unix(samba:session): session closed for user johndoe" ...

In journalctl output (also lightly redacted) it looks like this:
===============================================
Sep 08 21:47:20 machine smbd[144802]: pam_unix(samba:session): session closed for user johndoe
Sep 08 21:47:20 machine systemd[1601]: home-johndoe.mount: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- The unit UNIT has successfully entered the 'dead' state.
Sep 08 21:47:20 machine systemd[1]: home-johndoe.mount: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- The unit home-johndoe.mount has successfully entered the 'dead' state.
Sep 08 21:47:20 machine systemd[1]: smbd.service: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- The unit smbd.service has successfully entered the 'dead' state.
Sep 08 21:47:20 machine systemd[1]: Stopped Samba SMB Daemon.
-- Subject: A stop job for unit smbd.service has finished
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
===============================================

So in short: smbd closing the login session for my interactive user via pam_unix also pulls the mounted ecryptfs home folder out right from under "my feet". As you can imagine the symptoms after the ecryptfs home folder are unavailable are pretty inconvenient and I found no other remedy than to log out and back in to mitigate it. Yes, I am aware of ecryptfs-mount-private but that only helps for programs I know how to restart. I was unable to get the Plasma shell to restart and so basically the application menu was no longer listing most of the programs ...

But this means that evidently there is some session cleanup initiated by smbd which causes systemd to happily unmount my home folder. I apologize if this means I should have filed this with systemd as having the defect. It's presumably the interaction of both that causes this.

The gist of the smb.conf (before my workaround) as produced by testparm looks like this (redacted path, share and user names respectively):
===============================================
$ testparm|sed 's|'$(whoami)'|johndoe|g'
Load smb config files from /etc/samba/smb.conf
WARNING: The "syslog only" option is deprecated
WARNING: The "syslog" option is deprecated
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
debug uid = Yes
dns proxy = No
guest account = johndoe
log file = /var/log/samba/log.%m
map to guest = Bad Password
max log size = 1000
obey pam restrictions = Yes
panic action = /usr/share/samba/panic-action %d
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
passwd program = /usr/bin/passwd %u
security = USER
server role = standalone server
server string = %h server (Samba, Ubuntu)
syslog = 7
syslog only = Yes
workgroup = NULL
idmap config * : backend = tdb

[sharename]
force create mode = 0660
force directory mode = 0770
guest ok = Yes
guest only = Yes
path = /data/sharedir
read only = No
===============================================

MY WORKAROUND:

Right now (and for my use case that's perfectly fine, it seems) I have have simply set "obey pam restrictions = no" in smb.conf and retried with my above trial&error method and the issue can no longer be reproduced.

The version information requested in the Ubuntu bug reporting guidelines:
===============================================
$ lsb_release -rd
Description: Ubuntu 20.04.1 LTS
Release: 20.04
$ apt policy samba
samba:
Installed: 2:4.11.6+dfsg-0ubuntu1.4
Candidate: 2:4.11.6+dfsg-0ubuntu1.4
Version table:
*** 2:4.11.6+dfsg-0ubuntu1.4 500
500 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
500 http://de.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages
100 /var/lib/dpkg/status
2:4.11.6+dfsg-0ubuntu1 500
500 http://de.archive.ubuntu.com/ubuntu focal/main amd64 Packages
===============================================

If there is any information missing, please let me know and I'll try to amend the ticket.

I also asked about this over here https://unix.stackexchange.com/q/607508/5462 ...

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: samba 2:4.11.6+dfsg-0ubuntu1.4
ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55
Uname: Linux 5.4.0-47-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.8
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Tue Sep 8 22:09:33 2020
EcryptfsInUse: Yes
OtherFailedConnect: Yes
SambaServerRegression: Yes
SmbConfIncluded: No
SourcePackage: samba
TestparmExitCode: 0
UpgradeStatus: No upgrade log present (probably fresh install)

[Rafael David Tinoco (rafaeldtinoco)]

Thank you for reporting this, that was indeed a long bug description. I read it entirely - so you don't think I skipped any detail on purpose, If I did it was an accident - and the way I see this could be something as simple as:

SAMBA upstream has:

obey pam restrictions = no (by default)

and, according to man page:

      obey pam restrictions (G)

           When Samba 3.0 is configured to enable PAM support (i.e. --with-pam), this parameter
           will control whether or not Samba should obey PAM's account and session management
           directives. The default behavior is to use PAM for clear text authentication only and
           to ignore any account or session management. Note that Samba always ignores PAM for
           authentication in the case of encrypt passwords = yes. The reason is that PAM modules
           cannot support the challenge/response authentication mechanism needed in the presence
           of SMB password encryption.

           Default: obey pam restrictions = no

but the default we have in Debian/Ubuntu is "true". I could not find a specific reason to it.

----

From PAM.. the only thing I could notice is this:

/etc/pam.d/samba includes:

@include common-auth
@include common-account
@include common-session-noninteractive

and the difference between non-interactive and interactive is this setting:

session optional pam_systemd.so

that interactive session includes (and non-interactive does not).

----

The "session" comes from session-noninteractive PAM configuration file.

(1)

What do you have in that file ? I wonder if you're getting some kind of session timeout for your interactive and/or non interactive sessions.

(2)

What does it happen if you run sudo pam-auth-update and enables Unix authentication only ?

Nevertheless, this does not seem like a bug (yet ?) to me, but a misconfiguration.

[Rafael David Tinoco (rafaeldtinoco)]

Since it seems likely to me that this is a local configuration problem,
rather than a bug in Ubuntu, I am marking this bug as 'Incomplete'.

However, if you believe that this is really a bug in Ubuntu, then we would
be grateful if you would provide requested information in previous comments,
and then change the bug status back to "New".

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

[0xC0000022 (0xc0000022)]

Apologies, for leaving out that information. It was indeed not intentional.

Here follows the information for (1)

(The only redaction is stripping out the comments and empty lines)

===============================================
# grep -vP '^(#|\s*$)' /etc/pam.d/samba
@include common-auth
@include common-account
@include common-session-noninteractive
# grep -vP '^(#|\s*$)' /etc/pam.d/common-session-noninteractive
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_ecryptfs.so unwrap
===============================================

Please note that I did _not_ edit any of those files. `debsums -ce` is my witness 😉

Sorry for that negligence in not providing the PAM configuration. I did in fact also venture into PAM as I mentioned in my initial post. Alas, since I hadn't reconfigured anything PAM-related it made no sense that I caused this.

I'll follow up with the information concerning (2) shortly (and adjust the bug status). I have to give this as piecemeal because I am fully expecting that the plug is pulled on me w.r.t. my home folder.

[0xC0000022 (0xc0000022)]

Hah, thanks for your instructions they yielded results. For each of these tests I did the following.

* Reconfigured `pam-auth-update`
* I set `obey pam restrictions = Yes`
* Rebooted
* Checked whether the issue was reproducible
   * service restart smbd
   * check whether $HOME was still mounted
* Repeat

===============================================
Settings in pam-auth-update

[*] Unix authentication
[ ] Register user sessions in the systemd control group hierarchy
[ ] Create home directory on login
[ ] eCryptfs Key/Mount Management
[ ] Inheritable Capabilities Management

Restarted smbd and observed the log entry:

# tail -F /var/log/auth.log|rg samba:session
Sep 12 22:15:08 machine smbd[1839]: pam_unix(samba:session): session closed for user johndoe

$HOME was still available.

===============================================
Settings in pam-auth-update

[*] Unix authentication
[ ] Register user sessions in the systemd control group hierarchy
[ ] Create home directory on login
[ ] eCryptfs Key/Mount Management
[*] Inheritable Capabilities Management

Restarted smbd and observed the log entry:

# tail -F /var/log/auth.log|rg samba:session
Sep 12 22:24:27 machine smbd[1844]: pam_unix(samba:session): session closed for user johndoe

$HOME was still available.

===============================================
Settings in pam-auth-update

[*] Unix authentication
[ ] Register user sessions in the systemd control group hierarchy
[ ] Create home directory on login
[*] eCryptfs Key/Mount Management
[*] Inheritable Capabilities Management

Restarted smbd and observed the log entry:

# tail -F /var/log/auth.log|rg samba:session
Sep 12 22:27:31 machine smbd[1861]: pam_unix(samba:session): session closed for user johndoe

$HOME was unmounted!!!

===============================================
Settings in pam-auth-update

[*] Unix authentication
[ ] Register user sessions in the systemd control group hierarchy
[ ] Create home directory on login
[*] eCryptfs Key/Mount Management
[*] Inheritable Capabilities Management

Restarted smbd and observed the log entry:

# tail -F /var/log/auth.log|rg samba:session
Sep 12 22:32:57 machine smbd[1857]: pam_unix(samba:session): session closed for user johndoe

$HOME was unmounted!!!

===============================================

So, to summarize: the setting "eCryptfs Key/Mount Management" from pam-auth-update is what causes the behavior. So I guess this isn't related to Samba, but I would still consider this defective behavior nevertheless.

But honestly even if you close this and never did anything about it it would still help someone encountering this in future because of the search results.

[Rafael David Tinoco (rafaeldtinoco)]

Hello!

So, I'm happy it did work for you (at least as a mitigation, if not a bug resolution). I assigned this bug to myself so I don't loose track and will queue it in my mid-term (to come back) bug list if you don't mind. Just because, like you said, I want to make sure this behavior is ok.

That happens because of:

       pam_ecryptfs - PAM module for eCryptfs

I just wan't to make sure it is working as planned (or not) in a near future.

Thanks for reporting this!