--o3Y+93sjbn8Tp8J9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
  |=20
  | 	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
/{,s}bin).

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.]


Cheers,
Luke.

--o3Y+93sjbn8Tp8J9
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iD8DBQFA2ip+pBhtmn8zJHIRAkyNAKCNrMiuhoPJiiCW/E2ho55YwEOBqgCgqLEE
a4VFBWhSJOMAXUqssw2TC4Q=
=nZRf
-----END PGP SIGNATURE-----

--o3Y+93sjbn8Tp8J9--