Subject: Re: "su" in r escue?
To: Jun-ichiro itojun Hagino <email@example.com>
From: Luke Mewburn <lukem@NetBSD.org>
Date: 06/24/2004 11:12:30
Content-Type: text/plain; charset=us-ascii
On Thu, Jun 24, 2004 at 09:11:48AM +0900, Jun-ichiro itojun Hagino wrote:
| > What is wrong with using option -s booting into single user mode
| > or booting using a "rescue"-disk or cdrom in order to undertake
| > the required changes? I don't believe that adding complexity and
| > consequently bloat to the rescue binaries is the way to go when
| > alternative procedures are available.
| when you cannot do power-cycle + singleuser login, nor power-cycle +
| rescue-cd-boot, what would you do? i have been in such situation
| many times. most cases it is shlib issue.
The point of /rescue and "boot -sa" (to use "/rescue/init" as the
path to init(8)) is that you do not need a "rescue-cd-boot" to
recover from the situation that you're in.
Note that even before /rescue && fully dynamic userland, if you
hosed your shared libraries and you didn't have an active root
shell you couldn't run the dynamically linked /usr/bin/su to get
a root shell to use the (statically linked) /bin/mv to fix the
shared libraries. There has been no regression in this regard
(compared to functionality of the system with a statically linked
I consider it extremely risky to not have (remote) console access
of a system that you are maintaining, whether the userland is fully
dynamically linked or not; /rescue just makes the system more
robust in that situation.
There will be security concerns in the future if we provided a
statically linked (and possibly less functional) /rescue/su once
/usr/bin/su supports dynamically linked PAM modules, since users
could avoid the PAM policies for /usr/bin/su by running /rescue/su.
[All of these issues were covered when /rescue was first proposed.]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)
-----END PGP SIGNATURE-----