Tru64 privsep patch testing
David Potterveld
I can use gcc for debugging. I still prefer decc for production for various
reasons, including performance. I've traced the problem to an error return
from sia_ses_estab called by setup_sia in auth-sia.c.
I'm still investigating...
David Potterveld
_______________________________________________
openssh-...@mindrot.org mailing list
http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
David Potterveld
privileged and unprivileged processes, with both attempting to launch sia
sessions on the same (pseudo-)terminal. When I run the privileged process
in a debugger, with a breakpoint early in sia_setup, and then try to connect
with a client, the damn thing works. The privileged process stops at the
breakpoint, the unprivileged child forges ahead, and the client completes
the connection. I get a shell, and everything seems OK. X11 forwarding works
as well. Examining the data back in the parent, in the context of sia_setup,
I see it wants to launch a session on the same tty. The sia_ses_estab call
fails, and the parent exits, which brings down the working client session.
The next step for me is to try and figure out what the correct sequence of
sia calls from both priv and unpriv perspectives *should* be, and then how
to untangle them.
Ben Lindstrom
I assume you are going against --current or a more recent snapshot.
The patch was never designed to be applied again 3.4p1 tree. All testing
was done on --current.
- Ben
Toni L. Harbaugh-Blackford
> Hi Ben,
>
> > I assume you are going against --current or a more recent snapshot.
>
> Well, I was using 3.4p1. I just downloaded, patched, and built the
> 20020826 snapshot. This does behave differently... I ran sshd interactively
> (sshd -e -d -d -d) and tried to connect with a client. The privileged process
> commits the same error as before. The difference is that now it doesn't
> tear down the client session when it exits, and the client appears functional
> (warning: not tested yet beyond simply getting a shell.)
Yes, I saw this too.
> So it seems to me that
> there is still something wrong in the logic: at this point, the privileged
> process shouldn't be trying to launch another session on this tty, and it
> just happens to work now because the unprivileged process is better isolated.
Could you help me follow the code here (I'm getting lost between the unprivileged
and privileged processes)?...
Where does the unprivileged process setup it's session? Does setup_sia()
get called twice (once in the privileged process and once in the
unprivileged process) or is a different (non SIA) method used by the
unprivileged process?
-----------------------------------------------------------------------
Toni Harbaugh-Blackford harb...@nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center