openssh bugs - Jun 2006 - [Bug 926] pam_session_close called as user or not at all

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


carsten.benecke at rrz.uni-hamburg.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carsten.benecke at rrz.uni-
                   |                            |hamburg.de




------- Comment #16 from carsten.benecke at rrz.uni-hamburg.de  2006-06-22 18:04
-------
Hi Darren,

as the pam code has changed a lot, I wonder if you could please
summarize
the stat of the art?

Which process will call which pam function and how is this related to
the
privsep settings?

Regards,
CB




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

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





------- Comment #17 from dtucker at zip.com.au  2006-06-23 20:48 -------
(In reply to comment #16)
> as the pam code has changed a lot, I wonder if you could please
> summarize the stat of the art?
Changes since when?  We've been trying for incremental improvements for
a while...
> Which process will call which pam function and how is this related to
> the privsep settings?
This patch is not in the main code yet, but with it applied and
privsep=yes, the monitor will call both pam_session_open() and
pam_session_close() and will, I believe, solve the problem you
reported.  

With the patch applied and privsep=no, pam_session_open() will be
called by the process that later exec's the user's shell (I'm not
sure
pam_session_close() is called at all because the "session open" flag
isn't set in the parent... that's one of the next things to look at.)

Confirmation of whether or not it actually fixes your problem would be
appreciated.




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

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





------- Comment #18 from feldt at nhn.ou.edu  2006-06-24 00:26 -------
(In reply to comment #17)
> With the patch applied and privsep=no, pam_session_open() will be
> called by the process that later exec's the user's shell (I'm
not sure
> pam_session_close() is called at all because the "session open"
flag
> isn't set in the parent... that's one of the next things to look
at.)
> 
> Confirmation of whether or not it actually fixes your problem would be
> appreciated.
> 
I have just applied the patch to my Solaris 8 systems where the symptom
was that a root user (and only a root user) session would hang at
logout.

The patch solved this problem and has no immediate other side effects.




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

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


skunk at iSKUNK.ORG changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |skunk at iSKUNK.ORG




------- Comment #19 from skunk at iSKUNK.ORG  2006-06-24 04:33 -------
I've been bitten by this bug as well. (Want to do custom session
teardown as root. Currently, only "UseLogin yes" gets me there, but of
course that costs me X11 forwarding.)

I've applied patch 1143 to an openssh_cvs tree and tested on a
Debian/unstable Linux system. My observations:

1. pam_sm_{open,close}_session() are correctly invoked as root. (uid =gid ==
euid == egid == 0 for both)

2. Messages written to stdout/stderr in pam_sm_{open,close}_session()
are not visible to the user logging in or out. (I don't know if this is
by PAM's design or not.)

3. When running "sshd -de", messages written to stderr in
pam_sm_{open,close}_session() are visible in the server's stderr log.
Messages to stdout go nowhere that I can find.




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

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





------- Comment #20 from dtucker at zip.com.au  2006-06-24 11:19 -------
(In reply to comment #19)
> I've been bitten by this bug as well. (Want to do custom session
> teardown as root. Currently, only "UseLogin yes" gets me there,
but of
> course that costs me X11 forwarding.)
> 
> I've applied patch 1143 to an openssh_cvs tree and tested on a
> Debian/unstable Linux system. My observations:
Firstly, thanks for testing.
> 1. pam_sm_{open,close}_session() are correctly invoked as root.
Cool.
> 2. Messages written to stdout/stderr in pam_sm_{open,close}_session()
> are not visible to the user logging in or out. (I don't know if this
> is by PAM's design or not.)
PAM modules should not be writing to stdout or stderr.  If they have
something to say they should call the conversation function.  (There's
a simple example here:
http://www.zip.com.au/~dtucker/patches/pam_echo.c, which is based on
pam_echo from OpenPAM.)




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