☰

当 Samba 通过 PAM 关闭我的（交互式）用户的会话时，ecryptfs 安装的主文件夹“消失”

tag-icon • tag-icon ubuntu mount kde ecryptfs
当 Samba 通过 PAM 关闭我的（交互式）用户的会话时，ecryptfs 安装的主文件夹“消失”

在 Ubuntu 20.04 上 - 我之前在（普通）GNOME 中遇到过这种情况 - 使用 KDE Plasma （不，不是 Kubuntu！），我面临着每隔几个小时左右发生一次的奇怪的事情，对此我没有解释或补救措施截至目前。

不知何故，当我登录时安装的 ecryptfs 加密的主文件夹突然“消失”。我主要注意到它是因为奇怪的症状开始出现，例如各种程序报告$HOME他们找不到文件，他们认为这些文件已损坏，或者他们只是报告他们无法打开它们。

第一次发生这种情况时，我通常可以运行/usr/bin/ecryptfs-mount-private，输入我的密码并完成它。唉，这仍然无法恢复某些 KDE 桌面元素的功能。例如，从那时起我无法搜索已安装的程序，因此在我注销并重新登录之前，尚未运行的所有内容都将变得不可用。

随后发生这种情况，我尝试使用/usr/bin/ecryptfs-mount-private我通常会看到：

$ /usr/bin/ecryptfs-mount-private
Enter your login passphrase:
Inserted auth tok with sig [2123456789012312] into the user session keyring
mount: No such file or directory

即使在这种情况下注销也会成为一场小噩梦，正如您从下面的屏幕截图中看到的那样。弹出对话框只是基于我选择注销这一事实！

尝试注销时错误对话框的屏幕截图

所以我的问题（是的，复数......因为我目前不知道如何开始诊断这个问题）：

  1. 哪个实体可能导致我的自动删除$HOME？ ...我想起了奇怪的行为，例如当您注销时会话被清除，因此突然您的 Screen 或 Tmux 会话也被终止（除非您使用loginctlwith enable-linger）
  2. 解决此类问题的步骤是什么？ （请记住，发生这种情况时桌面的行为会很奇怪！）。我尝试使用 ripgrep 查看journalctl输出和日志，但我真的不知道要查找哪些术语......
  3. 假设这是一个已知的错误，如果有的话，解决方法是什么？

它让我想起了注销时 Tmux/Screen 被杀死的情况，这是我通常不会想到的情况，只能通过在登录 SSH（即单独的登录会话）后启动 Tmux/Screen 或启用会话延迟来防止这种情况。

我发现的一件事journalctl看起来很奇怪并且与“丢失的”主目录相关，如下：

Sep 01 23:39:11 machine smbd[220424]: pam_unix(samba:session): session closed for user johndoe
Sep 01 23:39:11 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 01 23:39:11 machine systemd[1977]: home-johndoe.mount: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--

...但这表明有些东西造成的由 Samba 守护进程代表我的交互式用户帐户导致系统的另一部分假设我注销并卸载我的$HOME...这听起来极不可能，不是吗？

上面的模式pam_unix(samba:session)关闭了我的用户名的会话，后跟$HOME文件夹变得无法访问是这确凿的证据，也是迄今为止唯一的一个。目前正在阅读整个会话业务应该如何工作以及为什么安装单元“认为”它可以在我仍然交互式登录时“收获”我安装的主文件夹。

编辑#1：由于注释表明 Samba 的配置可能相关，因此我将其添加到此处。我johndoe在转储中替换了我的实际用户名testparm：

# 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

正如您所说的那样，没有什么特别的，但我的猜测是，我通过全局设置“默认”我自己的用户作为来宾用户这一事实在某种程度上导致登录会话为我的用户显示。

samba:session除了少数几个条目（如上面复制的日志行）之外，没有任何带有标记的条目。

编辑#2：我的/etc/pam.d/samba样子是这样的：

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

...所以我尝试编辑这些引用的文件并在引用或 的debug每一行添加（用空格分隔）。结果 - 重新启动后 - 我根本无法再登录 KDE。它只是停滞了。因此，我使用其他终端之一登录并恢复我的更改（这要感谢这是微不足道的）。pam_unixpam_ecryptfsrootetckeeper

编辑＃3：KillExcludeUsers=root johndoe临时解决方法是通过设置/etc/systemd/logind.conf或“本地”为我的用户禁用会话延迟loginctl。这使得这看起来越来越像是一个缺陷。 ...编辑4：解决方法结果不起作用。

答案1

好吧，这当然很愚蠢，因为就在几个小时前我在赏金上“浪费”了 200 点声望，但我似乎已经解决了这个难题。任何提供比我更简单的注意事项和尝试提示的人都会获得赏金。

好吧，事实证明，pam_unix日志是一个重要的线索。我最终能够引发这种情况，从而可靠地重现卸载过程。

我所做的也有描述在 launchpad.net 上的相应票证中，但我将在这里重现上面问题中没有的相关部分。

我的smb.conf 前我深入研究了这个问题，根据testparm输出看起来像这样：

# 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

我选择了一种暴力试错方法。在 Tmux 中，我打开了几个窗格，同时尝试生成缺陷报告的 MWE。这实际上就是我正在运行的：

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

...然后在另一个 Tmux 窗口中编辑/保存/etc/samba/smb.conf.

砰!

显示auth.log日志条目 ( smbd[144802]: pam_unix(samba:session): session closed for user johndoe) 和安装点消失。

我终于找到了如何重现这种恼人的情况。

考虑到它的名字，我的第一选择确实是它obey pam restrictions的背景。所以我将其设置为no（但我可以简单地将其注释掉，因为它默认为no）。

重新启动smbd服务，注销并重新登录，并尝试再次重现错误情况。

这次无法重现。显然，obey pam restrictions环境影响了整个事情pam_unix和samba:session业务。

编辑#1：在里面提到的票要求提供更多信息。特别是在pam-auth-update我被要求停用除Unix认证环境。像这样：

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

事实证明，问题不是第二个与 systemd 相关的设置，而是第四个：eCryptfs 密钥/挂载管理。

得到教训

  1. 如果您要自己调查，请不要悬赏

相关内容