[EMAIL PROTECTED] writes:
> Same here. TIOSCTTY is a bezerkelyism. Just open /dev/ptmx, call grantpt(),
> and all unlockpt(). You also may or may not want to push the appropriate
> streams modules (ptem, ldterm, ttcompat). Same section of APUE.
I have one more question about how to use these functions. Currently,
lshd opens a pty-pair immediately when it receives the pty-request
messages. But at this time, the uid of the process is not quite right.
(The server have to open the slave with O_NOCTTY this time, I guess. I
have added this flag, but it is not in the latest snapshot).
In an attempmpt to get the right protection of the pty, lsh calls
grantpt() and unlockpt() *again* after forking (this is done in the
tty_setctty function in server_pty.c, called by the child).
And to finally make the tty the cntrolling tty of the child process,
we have to open it again, and close it immediately.
Are there any inherent problems with doing things this way? (One
reason to do it like this is that if pty allocation failes, for any
reason, lshd should be able to tell the client about it in the reply
to the pty-request message).
Do you have any description about the security issues in pty
allocation? I have the Solaris man-pages, and the UNIX98 docs (which
are very similar, as far as I have read), and I haven't found any
comprehensive description on what must be done to avoid things like
local users stealing eachother's ptys.
Anybody with a spare copy of APUE? ;)
Another option that would change this a little is to fork earlier. It
would like to have an option to fork and change uid immediately after
successful userauthentication. But the support for doing that (the
handling of the LSH_KILL_OTHERS status code) went away in the latest
rewrite of the io-backend, and it's not entirely trivial to fix.
/Niels
