[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#2916: sysvinit & single boot == broken



You (Christian Hudon) wrote:
> Maybe this should be documented better... (Read "somewhere else") All the
> people bred on Slackware (at least) are used to have "single" drop them
> more or less straight into a shell.

Nah, not really, it also does some other stuff (like automated fsck)
before starting the single user shell..

> It'd be nice to have a short file
> containing the kinds of details installed with base... The sysadmin could
> then be pointed to it after setting up root's password in the install. Or
> maybe we could just tell the sysadmin about "emergency" then.

Well if anyone feels to write a book about this.. Couldn't someone
adjust the "Linux Administrators Guide" by Matt Welsh for Debian?
I think it is more targetted at the Slackware of 1 or 2 years ago.
This would be nice to have!

> Hmm...  Does "linux emergency" try to invoke "sulogin" if the password
> file is ok, or does it really drop people straight into a root shell? IMHO
> the former would be better... Because otherwise bothering to invoke
> sulogin for "linux single" it pointless; 'evil people' will just learn to
> try "linux emergency" too.

No, it *always* executes "sulogin". Sulogin checks the password file for
correctness and if the password or shadow file is corrupt, it will just
give you a shell. Otherwise it will always ask for the root password.

Another problem is that newer kernels accept the "init=/bin/sh" parameter.
Also you can for example give the "LD_PRELOAD" variable to preload a
hacking library. So access to the bootprompt is _never_ safe.

A better solution would be to enhance LILO so that you can say which
command line arguments are allowed and which aren't... Any takers ? ;)

Mike.
-- 
  Miquel van    | Cistron Internet Services   --    Alphen aan den Rijn.
  Smoorenburg,  | mailto:info@cistron.nl          http://www.cistron.nl/
miquels@het.net | Tel: +31-172-419445 (Voice) 430979 (Fax) 442580 (Data)


Reply to: