bugzilla-daemon at mindrot.org
2006-May-22 05:12 UTC
[Bug 926] pam_session_close called as user or not at all
bugzilla.mindrot.org/show_bug.cgi?id=926 ------- Comment #8 from djm at mindrot.org 2006-05-22 15:12 ------- I don't understand - surely the limits should be applied in the *child* process and not the parent process? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2006-May-22 07:02 UTC
[Bug 926] pam_session_close called as user or not at all
bugzilla.mindrot.org/show_bug.cgi?id=926 ------- Comment #9 from t8m at centrum.cz 2006-05-22 17:02 ------- I am talking about your proposition in comment #6. It doesn't make sense because te pam_open_session + pam_close_session must be called by a parent process of the child from which the shell is executed but before forking the child so the child inherits limits and other things set by the session module. The reason why the pam_open_session cannot be called in slave is that the pam_close_session must be called in the same process as where the pam_open_session were. It also should be called with root privileges. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2006-May-22 09:03 UTC
[Bug 926] pam_session_close called as user or not at all
bugzilla.mindrot.org/show_bug.cgi?id=926 ------- Comment #10 from dtucker at zip.com.au 2006-05-22 19:03 ------- Created an attachment (id=1143) --> (bugzilla.mindrot.org/attachment.cgi?id=1143&action=view) Call pam_session_open and pam_session_close in monitor when privsep=yes With the above details in mind, I think this patch or similar is about as close as we can get. I suspect this may break pam_chroot when privsep=yes, though (since the monitor will also be chrooted). I would like to think that we can rationalize the PAM calls in session.c, but touching them usually results in problems, so it would need to be done very carefully. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2006-May-22 10:08 UTC
[Bug 926] pam_session_close called as user or not at all
bugzilla.mindrot.org/show_bug.cgi?id=926 ------- Comment #11 from t8m at centrum.cz 2006-05-22 20:08 ------- On the first look the current patch seems good, however it doesn't seem to solve the problem when privsep is disabled. Or am I wrong? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2006-May-22 11:16 UTC
[Bug 926] pam_session_close called as user or not at all
bugzilla.mindrot.org/show_bug.cgi?id=926 ------- Comment #12 from dtucker at zip.com.au 2006-05-22 21:16 ------- NO(In reply to comment #11)> On the first look the current patch seems good, however it doesn't seem > to solve the problem when privsep is disabled. Or am I wrong?No, you're right. It doesn't solve the issue when privsep=no. Fixing that means changing the way sshd works with PAM without privsep. We can do something similar to patch #1143 for that path, but that means moving the pam_setcred can pam_session_open calls to before the fork. This in turn means there will be no pty, and modules won't be able to interact with the user via the tty like they do now. I can't see a way to make both work simultaneously. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2006-May-22 11:26 UTC
[Bug 926] pam_session_close called as user or not at all
bugzilla.mindrot.org/show_bug.cgi?id=926 ------- Comment #13 from t8m at centrum.cz 2006-05-22 21:26 ------- That wouldn't be a good idea, because even the session modules should be able to communicate with the user. I think the most correct but a little bit bloated approach would be to do another fork (in privsep mode it would be in slave before dropping privileges) which would be there regardless of privsep setting. That's how login, gdm and other such programs work. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2006-May-22 11:39 UTC
[Bug 926] pam_session_close called as user or not at all
bugzilla.mindrot.org/show_bug.cgi?id=926 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dtucker at zip.com.au ------- Comment #14 from dtucker at zip.com.au 2006-05-22 21:39 ------- (In reply to comment #13)> That wouldn't be a good idea, because even the session modules should > be able to communicate with the user.They can communicate but it's one-way only (through Buffer loginmsg). This is how it works with privsep=yes (but folks have the option of setting privsep=no if they need this functionality, which is one reason I didn't change it in the patch).> I think the most correct but a little bit bloated approach would be to > do another fork (in privsep mode it would be in slave before dropping > privileges) which would be there regardless of privsep setting. That's > how login, gdm and other such programs work.I was wondering what login did. That means that the pam_session_close gets called by a different pid to the pam_session_open right? (although a direct descendant of it). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2006-May-22 21:07 UTC
[Bug 926] pam_session_close called as user or not at all
bugzilla.mindrot.org/show_bug.cgi?id=926 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wknox at mitre.org ------- Comment #15 from dtucker at zip.com.au 2006-05-23 07:07 ------- *** Bug 1189 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2006-May-22 21:08 UTC
[Bug 926] pam_session_close called as user or not at all
bugzilla.mindrot.org/show_bug.cgi?id=926 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |1155 nThis| | ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2006-Jun-06 17:48 UTC
[Bug 926] pam_session_close called as user or not at all
bugzilla.mindrot.org/show_bug.cgi?id=926 feldt at nhn.ou.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |feldt at nhn.ou.edu ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
Reasonably Related Threads
- [Bug 926] pam_session_close called as user or not at all
- [Bug 926] pam_session_close called as user or not at all
- [Bug 926] pam_session_close called as user or not at all
- [Bug 926] pam_session_close called as user or not at all
- [Bug 926] pam_session_close called as user or not at all