dan@rna.UUCP (Dan Ts'o) (06/22/84)
Hi, One reason I might do such a thing is to prevent passers-by from booting the system and getting a root shell. On my system, I replaced init's call to /bin/sh to /bin/login to achieve the same thing. I felt that the rare chance that /bin/login, /etc/passwd were corrupted but NOT /bin/sh was small compared to the value of not being able to get an easy root shell. Of course, if you are convinced that your computer room is absolutely safe from unauthorized access and that rebooting would be detected immediately, then this feature is less useful. Such is not the case in our environment, where persons knowledgible but NOT authorized to be root have access to the machine room. Making /bin/login the single-user command also aids in implementing an "operator" class of uids - people authorized to use certain commands such as fsck and dump but not become root. Cheers, Dan Ts'o ...cmcl2!rna!dan
wescott@ncrcae.UUCP (Mike Wescott) (06/23/84)
> From: dan@rna.UUCP (Dan Ts'o) > Newsgroups: net.bugs.usg > Subject: RE: Why does the S5 init run "/bin/su" in single-user mode > > Hi, > One reason I might do such a thing is to prevent passers-by from > booting the system and getting a root shell. On my system, I replaced > init's call to /bin/sh to /bin/login to achieve the same thing. I felt that > the rare chance that /bin/login, /etc/passwd were corrupted but NOT /bin/sh > was small compared to the value of not being able to get an easy root shell. Actually using login prevents this, but not /bin/su. Having been kicked off by a root uid proc /bin/su doesn't ask for a password. To make it difficult to reboot a Sys5 machine and get a root permission shell we change the default initial run level to kick off a single getty - login - shell sequence. And this does permit the creation of non-root operators for booting, fsck, et. al. BTW, we DID have a lightning storm that fouled up our disk; login, getty, /etc/passwd were all ok, but su, rm and a few others were corrupted. The machine didn't go down but you couldn't repair it except from the console. (We disable root logins except from the console.) Unfortunately, we tried rebooting first and went from a system that was crippled to one that looped endlessly trying to exec a froogged up /bin/su. As for the original question of why init kicks off /bin/su in the single user state...the question is still open. Mike Wescott NCR Corp mcnc!ncsu!ncrcae!wescott
guy@rlgvax.UUCP (Guy Harris) (06/23/84)
See response in "net.unix-wizards" on this.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guykae@ihuxl.UUCP (Alan Edwards) (06/26/84)
Maybe it's set to /bin/su so that a 'favorite' shell can be used! After all su does look up the suee's SHELL string in /etc/passwd. -- -Alan Edwards IX 1C-423 x0879 (ihuxl!kae)