Date: Wed, 15 Dec 2004 12:18:38 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Matthias Andree <ma@dt.e-technik.uni-dortmund.de> Cc: current@FreeBSD.org Subject: Re: Background fsck is broken Message-ID: <44115.1103109518@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 15 Dec 2004 12:09:21 %2B0100." <m33by7zula.fsf@merlin.emma.line.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <m33by7zula.fsf@merlin.emma.line.org>, Matthias Andree writes: >"Poul-Henning Kamp" <phk@phk.freebsd.dk> writes: > >> In message <20041215105326.GO25967@ip.net.ua>, Ruslan Ermilov writes: >> >>>Are you saying it's not possible to downgrade the open to >>>(r=1, w=0, e=0) when a file system is downgraded from R/W to R/O? >> >> Yes: that would make a read-only mounted filesystem vulnerable to >> overwriting through the /dev entry and we don't want that. >> >> The problem is that we do not in the kernel know if we are in single >> user mode or not. > >What difference does this make? Aren't secure levels or mandatory access >control and similar schemes sufficient to prevent tampering with direct >device access? No. >Why would not root be allowed to nuke a read-only mounted file system? >root has other means to trash a system, including writing junk into the >hardware registers. Just because root can go out of his way to do something stupid doesn't mean that we should make it easier to make an honest mistake. >On my wishlist, I've always wanted a "networked single user mode" >(i. e. only sshd running, only root login with key possible), and I've >always wondered why the whole system recovery is focused so much on the >principle of a "single-user console". Implement it! I've wanted that for a long time too. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44115.1103109518>