bill@contex.UUCP (Bill Phillips) (08/31/90)
The following was bounced, so I figured I might as well post it: ----- Transcript of session follows ----- >>> RCPT To:<schuman@odin.corp.sgi.com> <<< 550 <schuman@odin.corp.sgi.com>... User unknown 550 <@relay.corp.sgi.com:schuman@odin.corp.sgi.com>... User unknown ----- Unsent message follows ----- Received: from gate-shinobu.sgi.com by palladium.corp.sgi.com (5.52/900721.SGI) for schuman@odin.corp.sgi.com id AA01738; Thu, 30 Aug 90 15:02:42 PDT Received: from relay.sgi.com by shinobu.sgi.com (5.52/891101.SGI) for @relay.corp.sgi.com:schuman@odin.corp.sgi.com id AA05348; Thu, 30 Aug 90 15:02:39 PDT Received: from sgi.sgi.com by relay.sgi.com (5.52/900423.SGI) for shinobu.sgi.com!odin!schuman id AA00418; Thu, 30 Aug 90 15:02:37 PDT [... intermediate hops omitted ...] Received: by contex.xds.xyvi.com (5.52/890607.SGI) (for uunet!cs.utexas.edu!sdd.hp.com!decwrl!sgi!shinobu!odin!schuman) id AA23905; Thu, 30 Aug 90 17:42:32 EDT Date: Thu, 30 Aug 90 17:42:32 EDT >From: shinobu.sgi.com!relay.sgi.com!SGI.COM!decwrl.dec.com!hplabs!uunet.UU.NET!contex!bill (Bill Phillips) Message-Id: <9008302142.AA23905@contex.xds.xyvi.com> To: uunet.UU.NET!uunet!cs.utexas.edu!sdd.hp.com!decwrl!sgi!shinobu!odin!schuman Subject: Re: rsh (remote shell) -- undocumented(?) feature(?) Newsgroups: comp.sys.sgi In-Reply-To: <1990Aug29.014812.14956@odin.corp.sgi.com> References: <1406@contex.UUCP> Organization: Xyvision Design Systems, Wakefield, MA Cc: In article <1990Aug29.014812.14956@odin.corp.sgi.com> you write: :I just looked over the source for rshd, and I didn't see it setting :umask anywhere. It isn't set in rcmd(3) either. Doing a setuid :system call doesn't source the rc files belonging to the new user, :so umask isn't getting set that way. : :The umask shell variable is inherited by child processes. My guess :is that on your system rshd's parent (inetd) has a umask of 022, :and so does rshd's grandparent (init). 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. Indeed, we just reloaded a system from scratch, and when we rsh <name> umask, we get 22. 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. Incidentally, I gather there is an undocumented flag ("-d") for inetd. Do you know what it is for? Thanks, bill -- William F Phillips, Sr. Engr., Development Systems Development Group, Xyvision Design Systems + 101 Edgewater Drive + Wakefield, MA, USA uunet!contex!bill (formerly wfp@well & wfp@dasys1) -- William F Phillips, Sr. Engr., Development Systems Development Group, Xyvision Design Systems + 101 Edgewater Drive + Wakefield, MA, USA uunet!contex!bill (formerly wfp@well & wfp@dasys1)
brendan@illyria.wpd.sgi.com (Brendan Eich) (09/01/90)
In article <1410@contex.UUCP>, bill@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)
schuman@sgi.com (Aaron Schuman) (09/04/90)
William F Phillips, Sr.> there is an undocumented flag ("-d") for inetd.
William F Phillips, Sr.> Do you know what it is for?
It's a debug option. All it does is throw a few remarks into the syslog.
Aaronschuman@sgi.com (Aaron Schuman) (09/04/90)
William F Phillips, Sr.> Do you know what it [inetd -d] is for? Me> It's a debug option. All it does is throw a few remarks into the syslog. Oops. Brendan is right. I was wrong. It does more than fill syslog. It keeps inetd from backgrounding itself.