Jonathan McDowell <[EMAIL PROTECTED]> writes:
> This is something I'd really like to see too. I've spent half an hour or
> so playing with the login.c from OpenSSH 1.2 and trying to integrate it
> into lsh, but all I seem to have managed to do is make it segfault
> several times.
Kewl. One difference between lsh and most other programs is the pty
handling. The pty for the child process is allocated a long time
before forking and uid switching happens.
> Am I right in saying that we can assume we've logged in if we get to the
> parent bit after the fork in do_spawn_shell() in server_session.c? And
> when can we assume we've logged out? do_exit_shell(), also in
> server_session.c?
I think you're right, but it depends on how you define "login" and
"logout". When we get to do_spawn_shell, the user has been
authenticated properly, and has requested that the server start a
login shell for him/her.
So that would be a reasonable place. When getting to the parent case,
a child process has been spawn successfully. But this may be a little
to late, if you want to make sure that the user is registered as
"logged in" *before* the shell starts executing. A better place might
be in the "child" case, i.e. between fork() and exec() (or more
likely, between fork() and change_uid(), if the login processing
requires privileges).
One problem with debugging process creation is that the child
will typically crash if it hits a break point. You may want to add an
int hang=1;
while(hang) sleep(10);
first in the child process, so that you can attach to it with a
debugger. Or something like that.
do_exit_shell seems to be the natural place to do logout processing. It
is called after the child process has died. Of cource, there might
still be grandchildren processes left.
/Niels
