40d1117791
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. |
||
|---|---|---|
| .. | ||
| inetd.8 | ||
| inetd.c | ||
| Makefile | ||
| pathnames.h | ||