Date: Fri, 03 Nov 1995 03:12:25 -0800 From: David Greenman <davidg@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 Message-ID: <199511031112.DAA00303@corbin.Root.COM> In-Reply-To: Your message of "Fri, 03 Nov 95 01:30:16 PST." <199511030930.BAA01125@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511031112.DAA00303>