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

http://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.

http://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.

http://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)
 --> (http://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.

http://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.

http://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.

http://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.

http://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.

http://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.

http://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.

http://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.