From owner-cvs-usrsbin  Fri Nov  3 01:30:27 1995
Return-Path: owner-cvs-usrsbin
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id BAA01136
          for cvs-usrsbin-outgoing; Fri, 3 Nov 1995 01:30:27 -0800
Received: (from peter@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id BAA01125
          ; Fri, 3 Nov 1995 01:30:16 -0800
Date: Fri, 3 Nov 1995 01:30:16 -0800
From: Peter Wemm <peter>
Message-Id: <199511030930.BAA01125@freefall.freebsd.org>
To: CVS-commiters, cvs-usrsbin
Subject: cvs commit: src/usr.sbin/inetd inetd.c
Sender: owner-cvs-usrsbin@FreeBSD.org
Precedence: bulk

peter       95/11/03 01:30:15

  Modified:    usr.sbin/inetd  inetd.c
  Log:
  Workaround for the setlogin()-in-same-session-as-inetd bug.
  
  This causes:
  1: inetd to clear it's getlogin() name at startup (in case the sysadmin
  	logged in and su'ed to root and restarted inetd)
  2: inetd to start each spawned process in it's own session.
  3: inetd to call setlogin() on non-root processes (eg: uucp for uucico)
  4: log failures more extensively
  
  This means that root spawned processes from inetd remain responsible for
  setting their login name if they change their uid. (eg: rshd, login, etc).
  
  If they do not do so, it is safer for them to have no "login name" than a
  wrong one (like "root") because the getlogin() system call is documented
  as "secure" on 4.4BSD.  inetd when started from /etc/rc would have no login
  name anyway, so this isn't really a change - it's making it consistant with
  the bootup state...
  
  The setsid() change *may* cause something to break that is doing a setsid()
  itself and checking the result - it will fail now because it's already been
  done.  The consensis seems to be that this is unlikely. David G. thinks
  this is acceptable as it is cleaner from an architectural point of view.