[Bug 926] pam_session_close called as user or not at all

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Mon May 23 19:36:52 EST 2005


http://bugzilla.mindrot.org/show_bug.cgi?id=926





------- Additional Comments From dtucker at zip.com.au  2005-05-23 19:36 -------
(In reply to comment #5)
> I'm not sure if I understand your proposal well so I only make some remarks
> how from the PAM point of view it should be done.

Ah, but which PAM's view? :-)

> The pam_setcred(PAM_ESTABLISH_CRED) should be called before pam_open_session

I know that's what the LinuxPAM man page says, but the Sun PAM man page says the
opposite:

     The pam_setcred() function is used to establish, modify,  or
     delete  user  credentials.  It is typically called after the
     user has been authenticated and after  a  session  has  been
     opened.   See  pam_authenticate(3PAM),  pam_acct_mgmt(3PAM),
     and pam_open_session(3PAM).

FWIW I think the Sun approach is saner since it means that pam_setcred can drop
privs (or chroot, or whatever) and pam_open_session still has privs to write
whatever records it needs to.

[...]
> The pam_close_session call should be done in the same process.

The open+close in the same process is doable, however setcred in the same
process (or the parent thereof) as the session is a problem.  In the privsep
case, what I'm proposing is roughly this:

(monitor) forks slave
(slave) setcred(ESTABLISH_CRED), setgid, setuid
(slave) requests pty from master
(monitor) allocates pty, calls pam_open_session
(slave) forks shell process
(shell) does stuff
(shell) exits
(slave) requests session close from master
(monitor) calls pam_close_session
[connection closes]
(slave) setcred(DELETE_CRED)
(slave) exits
(monitor) exits

So, the session open/close would happen purely in the monitor, and the
establish/delete creds happen purely in the slave.

It basically boils down to this: does pam_{open,close}_session represent an
interactive (ie shell) session or an authentication session?  I suspect the
answer is "depends on the module" (which is one of the fundamental problem with
PAM...).



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.




More information about the openssh-bugs mailing list