Mailing List Archive

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





------- Comment #9 from t8m@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.

_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-bugs

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





------- Comment #10 from dtucker@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.

_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-bugs

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





------- Comment #11 from t8m@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.

_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-bugs

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





------- Comment #12 from dtucker@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.

_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-bugs

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





------- Comment #13 from t8m@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.

_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-bugs

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


dtucker@zip.com.au changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |dtucker@zip.com.au




------- Comment #14 from dtucker@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.

_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-bugs

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


dtucker@zip.com.au changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |wknox@mitre.org




------- Comment #15 from dtucker@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.

_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-bugs

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


dtucker@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.

_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
http://www.mindrot.org/mailman/listinfo/openssh-bugs