>I might add that to be able to unmount /usr, if that is indeed where
>/usr/bin/login is being run from, or any other filesystem for that
>matter, it needs to be totally unused. For this reason, I think you
>would be hard pressed to have /usr unmounted in a manner that would
>go undetected unless you were in single luser mode. Depending on
>what else runs on the system and how packages are installed, the
>same might be true for other file systems often used for installation
>of binaries (/usr/local). To give you some idea of the programs which
>would need to have been stopped before unmounting /usr are as follows:
>
>syslogd, update, cron, inetd, getty
>
>(according to NetBSD-1.4). That said, I do think that the claims made
>by the documentation for securelevel 1 are false and should instead
>mention something about changing file flags through "conventional means"
>with a more complete briefing available for securelevel 2.
Right. You will run in trouble if you try to umount /usr without
'preparing' the system for it. To do this you also have to link UZip statically
b/c libc is in /usr. This also means the other programs as syslogd etc.
Some of them (getty) will die without explicitly kill them.
Althought hard, it's not impossible and on my test system i was able to remove
an immutable /usr/bin/login _without_ booting into single user (why the hell 'user'
isn't it for root? :-) mode.
Regardless whats written in the README, you have to define FORCE_OR_NOT to
MNT_FORCE (not 1) if it should be done the 'umount -f' way, sorry.
Stealth
: ---- main(){fork();main();} ----
: Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
: Stealth <-> http://www.kalug.lug.net/stealth
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:51:39 PDT