dan@rna.UUCP (Dan Ts'o) (04/01/85)
Hi, Your suggestion to mount the ROOT filesystem at UNIX initialization time *should* work. But besides calling mountfs() in main() with 1 to flag a readonly rootdev, there may be other problems to deal with (some difficult to predict without trying). You mentioned wanting to put /dev/kmem on this readonly rootdev. I assume you wanted this as extra protection so you couldn't write on /dev/kmem even if the write permissions were on. (This doesn't make much sense to me...) In any case, if you look in access() in 4.2BSD, it checks if the inode being opened is a char or block dev and *allows* write access *even* if the inode is on a readonly filesystem. (Some older UNIX systems do not check this case.) Even if you commented out this check, a bad side effect would be that nobody could open /dev/tty* for writing. Since pipes in 4.2BSD are not inodes but sockets, you're okay here. Older UNIX's would have to make sure (I think) that pipedev was not readonly. Swapdev in 4.2BSD is almost never the root filesystem partition and would never be a part of the root filesystem itself. There are a few files which UNIX like to write on in the root filesystem. These would have to be moved, either by changing programs and utilities to use different path names which reside on writeable filesystems, mounting a writeable filesystem on the relevent directory, or using symbolic links to point to a file in a writeable filesystem. One such file that comes to mind is /etc/utmp. There may be others. I believe that what you want is quite do-able, but it might take a little experimentation. Certain UNIX is general is amenable to the idea. Something similar and (probably) far more work was done in the HP Integral. Cheers, Dan Ts'o Dept. Neurobiology Rockefeller Univ. 1230 York Ave. NY, NY 10021 212-570-7671 ...cmcl2!rna!dan
jsdy@hadron.UUCP (Joseph S. D. Yao) (04/11/85)
The Air Force Data Services Centre (AFDSC) at the US Pentagon long
ago set up their system like this, so that they could distribute a
version of UNIX that they could also maintain. It was on one of
the early UNIX Users' Group software distribution tapes. I believe
that they did move a bunch of stuff out of /etc. I'm not sure.
I know the current net address of one of the implementors, but am
reluctant to broadcast it without his permission. Would someone at
MITRE ask Walt if he minds saying a word about this?
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}lazear@mitre.ARPA (Walt Lazear) (04/16/85)
The Air Force did indeed use a form of read-only root filesystem, as a
strategy to avoid the hassles of integrating software releases into
operational filesystems. All we distributed was a root on which there
should be no lasting changes, so that if it crashed or trashed, you
could read a fresh copy from the distribution tape (we duplicated the
original Bell 'tp' format for distribution tapes).
Two points, however. First, we found we could not mount the root truly
read-only. There are updates to inodes (I forget what, but probably
last accessed times) that must occur, so we lived with a normally mounted
root that could be 'refreshed' at any point by reading in a new copy.
The second point is even more important. IT WAS A LOT OF WORK TO GET THERE!!
The overall scheme was to have the /usr filesystem be where volatile and
site specific stuff resided. As Joe Yao pointed out, that means moving
Bell supplied programs from /usr/bin to /bin, and databases from /etc
(passwd, group, ttys) to /usr/etc. You would be amazed at how incestuous
programs were, even back in V6! One would call another to do certain
functions, and would use an absolute pathname (not unreasonable, since
there were no search rules with exec(2)). All references to /usr/bin
had to be changed to /bin and programs recompiled (before 'make' was
around).
Overall, the effort was worth it. Sites had merely to boot a new root
to activate the software release, they did not have to dump that filesystem
(ever) because they had a copy sitting on the distribution tape, and
their local applications were nicely partitioned from system stuff.
Alas, all this disappeared when they bit the bullet and adopted SysIII and
SysV, but they decided not to be the central distribution center for the
Air Force any longer. Sites should go directly to ATT for software and
support (and to fend for themselves generally).
Sorry to go on so long, but I wanted to indicate that there was merit in
the idea, especially when you might be supporting distant sites (ours were
in Mississippi, Alabama, and Ohio, while we were in the Pentagon in DC)
with inexperienced word processor operators as your system administrators.
Walt (Lazear at MITRE)ron@BRL-TGR (Ron Natalie) (04/16/85)
Our BRL/JHU UNIX systems (which are a hodge podge of various versions of UNIX) will run with a physically right protected route. -Ron
jack@boring.UUCP (04/17/85)
>Our BRL/JHU UNIX systems (which are a hodge podge of various versions of >UNIX) will run with a physically right protected route. ^ This means you'll construct a freeway with a wall on the right- handside??????? (Sorry, couldn't resist:-) -- Jack Jansen, {decvax|philabs|seismo}!mcvax!jack The shell is my oyster.