openssh unix dev - Sep 2002 - tru64 sia: move call of session_setup_sia() to do_setusercontext(), letting grantpty() and friends handle pty perms

Hi-

Under privsep, I experimented with moving the session_setup_sia() out of
do_child() and into do_setusercontext(), which is where the uids/gids are set
to the final execution user.  The call is made with a NULL tty, and this
is functional provided that any later pty allocation uses grantpty() to
set the device permissions.  Logging in with this method shows that a utmp
entry does get made for the tty.  There are several issues I see with this
configuration, but I don't think any pose insurmountable problems:

   - There is an #if'd-out call to do_setusercontext() in the subroutine
     privsep_preauth_child(), which means that the SSH_PRIVSEP_USER would
     be run through the session_setup_sia() should the '#if 0'
preprocessor
     directive be removed.  I don't want SSH_PRIVSEP_USER to be passed
     through session_setup_sia(), because I like that account to be locked
     and the session setup stuff would fail in this case.  So for HAVE_OSF_SIA
     this should stay #if'd-out.

   - If you are using the audit subsystem, the link between a tty and
     successive processes may be lost in the audit records.  But I do
     extensive auditing, and ptys seem to be pretty much useless in audit
     trails; it's the process tree that is most useful.

   - Tru64 5.0x has the /dev/ptmx device, so the HAVE_DEV_PTMX logic can be
     used to access grantpty() in sshpty.c.  But OS versions prior to 5.0x do
     not have /dev/ptmx, although they *DO HAVE* grantpty.  So appropriate
     changes and testing will have to be done for earlier versions to see
     that grantpty() and all the terminal setup gets done appropriately.

   - Since session_setup_sia() works in do_child() when privsep is NOT
     in use, I'm fairly sure we want to leave it there in that case.
     It can safely override any grantpty() settings.

   - stty terminal settings are screwy when privsep is used, and I don't
     know why.  It may relate to the fact that the tty is not initialized by
     the sia stuff, but I have to admit that I haven't delved into the
details
     of this yet.  It seems that the terminal settings could be corrected
     outside of SIA.

Does anyone see any other problems with moving session_setup_sia() to
do_setusercontext() when privsep is in use?  Any comments on the
list above?

Toni

-----------------------------------------------------------------------
Toni Harbaugh-Blackford                     harbaugh at nciaxp.ncifcrf.gov
AlphaServer 8400 System Administrator
SAIC/NCI Frederick Advanced Biomedical Computing Center

Once upon a time, Toni L. Harbaugh-Blackford <harbaugh at
nciaxp.ncifcrf.gov> said:
> Does anyone see any other problems with moving session_setup_sia() to
> do_setusercontext() when privsep is in use?  Any comments on the
> list above?
The biggest one is that you lose functionality from the SIA layer.  If
SIA doesn't have a terminal, it can't tell the user their password is
expired or their account is locked (or the last successful and failed
logins), the user can't change expired password at login, etc.  Any of
that will just cause the connection to fail silently, which IMHO is not
acceptable.

Obviously right now, the connection will fail silently for non-TTY
logins to locked accounts, etc., but an TTY login will give the user the
error.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.