From owner-cvs-usrsbin  Fri Nov  3 03:13:43 1995
Return-Path: owner-cvs-usrsbin
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id DAA05735
          for cvs-usrsbin-outgoing; Fri, 3 Nov 1995 03:13:43 -0800
Received: from Root.COM (implode.Root.COM [198.145.90.17])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA05719
          ; Fri, 3 Nov 1995 03:13:31 -0800
Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id DAA04060; Fri, 3 Nov 1995 03:12:55 -0800
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id DAA00303; Fri, 3 Nov 1995 03:12:25 -0800
Message-Id: <199511031112.DAA00303@corbin.Root.COM>
To: Peter Wemm <peter@freefall.freebsd.org>
cc: CVS-commiters@freefall.freebsd.org, cvs-usrsbin@freefall.freebsd.org
Subject: Re: cvs commit: src/usr.sbin/inetd inetd.c 
In-reply-to: Your message of "Fri, 03 Nov 95 01:30:16 PST."
             <199511030930.BAA01125@freefall.freebsd.org> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Fri, 03 Nov 1995 03:12:25 -0800
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.

   Heh..trying to blame ME for it, huh? :-)

   I'll also point out that both Mike Karels and Kirk McKusick reviewed this
change.

-DG