Date: Wed, 01 May 2002 23:00:43 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: utsl@quic.net, "Andrew P. Lentvorski" <bsder@allcaps.org>, freebsd-fs@freebsd.org Subject: Re: Non-standard root filesystems Message-ID: <3CD0D60B.C629901E@mindspring.com> References: <200205012027.aa63727@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian Dowse wrote: > I presume you know that FreeBSD already allows you to mount another > filesystem directly over /? Do you actually need to remove the > original root filesystem, or is it just for cosmetic reasons that > you would like it to disappear from the mountlist? My first thought, as well. But the problem is really deeper than that; doing a mount-over will not maintain the already covered mount points, particularly if there are missing intermediate directories. > One think I have thought about before, but never actually tried > implementing, is to permit the root filesystem to be forcibly > unmounted so long as there is another filesystem mounted directly > above it to become the new root (you obviously have to specify the > root filesystem by device name). That might be relatively easy to > do, and it doesn't require a new system call. To do this requires violating the stacking abstraction. By doing this, you would grant indirect access to underlying FSs to areas which have been mounted over. The worst case scenario here is a cryptographic FS stacking layer mounted over top of the FS that it's stacked on top of, which uses metadata obtained by directory or other namespace folding. By doing this, it's possible to access the cleartext and the ciphertext simultaneously, which would permit recovery of the "pad". After that, revocation of access is imposible. Worse, it's possible to replace the ciphertext with all zeros, recover the pad from a reading of the exposed ciphertext without a key, reverse the process to replace the zeros with the cipher text, and then reading the other ciphertext, merely XOR it with the recovered pad, allowing you to decrypt the data without a key. You *really* don't want to allow this. > There are a few problems though: I think init(8) would need to have > a signal that causes it to re-exec itself, since otherwise it could > get killed if any of the executable needed to be paged in. A more correct approach would probably be to provide a static root, and then union mount the "real" root over the static root. I suggested this a long, long time ago (1996) for the devfs, which would mount the devfs automatically on /dev, and then root would be mounted union over the / part of /dev/, leaving the /dev/ contents intact. This would, as a side effect, provide the persistance in /dev that everyone always bitches about for permissions, deletions, etc.. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD0D60B.C629901E>