bounced mail

[Brendan Eich]

In article <1410 at contex.UUCP>, bill at contex.UUCP (Bill Phillips) writes:
> Well, a bit more investigation turned up the fact that this problem
> only occurs on machines running IRIX 3.3.  inetd on these machines 
> seems to set/inherit the umask of 0022, whereas the ones under 3.2
> do not.  There appears to be no difference in the way inetd is started up
> on the two systems.
> [. . .] 
> We are reporting this to the sgi hotline, but it's really  driving me nuts
> that I can't find out why this is happening.

Historically, proc[0] in Unix, hand-crafted by the kernel's main(), had
a umask of 0.  Proc[1], init, inherited this umask, as did all processes
spawned by init.  BSD changed proc[0]'s umask to 022, as the number of
daemons descended from init increased the likelihood of a critical file
or directory being created with group and other write permission.

In 3.3, we caught up with Berkeley's safeguard against holes such as a
writable /etc/utmp, by changing proc[0]'s umask to 022.  Init(1M) uses
fopen(3S) to create utmp, and fopen calls open(2) with mode 0666.  This
is arguably an init bug, but if proc[0]'s umask had been kept 0 and all
nine hundred daemons were "fixed" with more complex code to open using
0600 (and then fdopen for stdio use), the system would be fatter and
probably buggier, with little gain for users.

(SVR4 does change umask to 022 temporarily in init when creating utmp,
and SunOS likewise seems to keep proc[0]'s umask zero.  Don't take my
"fatter and probably buggier" above as a comment on SVR4 or SunOS :-)

Since there's a workaround, and we're 4.3BSD compatible as far as rshd
is concerned, and verifying system process security is harder if system
processes inherit a zero umask, we probably won't change it back to 0
till the V.4 millenium arrives, or soon thereafter.

> Incidentally, I gather there is an undocumented flag ("-d") for inetd.
> Do you know what it is for?

It's a debugging option, for internal use.  Developers may use -d to keep
inetd from backgrounding itself and closing standard i/o.  Usually you'd
do this only when debugging inetd, so we don't document it for customers.
If someone were to add it to inetd's invocation in /etc/init.d/network,
the system would hang soon after the next reboot.

Brendan Eich (speaking for himself, not SGI)