![Samba가 PAM을 통해 내 (대화형) 사용자 세션을 닫으면 ecryptfs 설치의 홈 폴더가 "사라집니다"](https://linux55.com/image/179517/Samba%EA%B0%80%20PAM%EC%9D%84%20%ED%86%B5%ED%95%B4%20%EB%82%B4%20(%EB%8C%80%ED%99%94%ED%98%95)%20%EC%82%AC%EC%9A%A9%EC%9E%90%20%EC%84%B8%EC%85%98%EC%9D%84%20%EB%8B%AB%EC%9C%BC%EB%A9%B4%20ecryptfs%20%EC%84%A4%EC%B9%98%EC%9D%98%20%ED%99%88%20%ED%8F%B4%EB%8D%94%EA%B0%80%20%22%EC%82%AC%EB%9D%BC%EC%A7%91%EB%8B%88%EB%8B%A4%22.png)
Ubuntu 20.04에서 - 이전에 (일반) GNOME에서 이 문제를 겪은 적이 있습니다. - KDE 플라즈마(아니요, 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
아래 스크린샷에서 볼 수 있듯이 이러한 상황에서는 로그아웃하는 것조차 약간의 악몽이 될 수 있습니다. 팝업되는 대화 상자는 내가 로그아웃을 선택했다는 사실을 바탕으로 한 것입니다!
그래서 제 질문은 다음과 같습니다(예, 복수형입니다... 현재 이 문제를 어떻게 진단해야 할지 모르기 때문입니다).
- 자동 삭제의 원인이 될 수 있는 항목은 무엇입니까
$HOME
? ...로그아웃하면 세션이 지워져서 갑자기 Screen 또는 Tmux 세션도 종료되는 등의 이상한 동작이 생각납니다( 와loginctl
함께 사용하지 않는 한enable-linger
) . - 그러한 문제를 해결하기 위한 단계는 무엇입니까? (이런 일이 발생하면 데스크탑이 이상하게 작동한다는 점을 명심하십시오!) 출력과 로그를 보기 위해 ripgrep을 사용해 보았
journalctl
으나 어떤 용어를 찾아야 할지 잘 모르겠습니다... - 이것이 알려진 버그라고 가정하면 해결 방법은 무엇입니까?
이는 로그아웃 시 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_unix
pam_ecryptfs
root
etckeeper
편집 #3: ...EDIT 4: 해결 방법이 작동하지 않는 것으로 나타났습니다.KillExcludeUsers=root johndoe
임시 해결 방법은 /etc/systemd/logind.conf
설정이나 "로컬"을 통해 사용자에 대한 세션 지연을 비활성화하는 것 입니다 loginctl
. 이로 인해 이것이 점점 더 결함처럼 보입니다.
답변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를 생성하는 동안 여러 개의 창이 열려 있습니다. 이것이 실제로 제가 실행하고 있는 것입니다:
while mountpoint /home/johndoe; do sudo service smbd restart; date; sleep 2s ; done
watch 'mount|grep ecryptfs'
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 authentication
[ ] Register user sessions in the systemd control group hierarchy
[ ] Create home directory on login
[ ] eCryptfs Key/Mount Management
[ ] Inheritable Capabilities Management
문제는 두 번째 systemd 관련 설정이 아니라 네 번째 설정인 것으로 밝혀졌습니다.eCryptfs 키/마운트 관리.
교훈을 얻으세요
- 직접 조사하고 싶다면 현상금을 제공하지 마세요.