On Tuesday 12 August 2003 13:08, Brian Richardson wrote:
> On August 9, 2003 07:22 am, Gareth Jones wrote:
> > I would like to make root read only, but it seems that this is not
> > possible. I've put /var, /home, /tmp and /usr one different file
> > systems, and that works ok - but gentoo writes to /etc during bootup. I
> > can't put /etc on a separate file system, because it is needed during
> > boot.
>
> AFAIK, mount hardcodes the the mtab to be in /etc, meaning that /etc
> can't be on a separate partition, nor a read-only partition. The best you
> can do is to keep a daily backup of your /etc partition, and ensure the
> file permissions are as restrictive as possible (ie. chmod 400/444
> <file>). However, you may want to look for diskless setup HOWTOs, as this
> issue must be addressed in a diskless boot. Finally, you could also have
> a script similar to the *BSD daily output/insecurity logs to keep track
> of changes to critical configuration files.


I don't know why mount, as well as, other programs (dhcpcd, etc.) still use 
/etc for run-time variable data or variable state information.  Other than 
the fact that etc is almost always part of the root partition and mounted 
read / write.

From the mount man page:

The programs mount and umount maintain a list of currently mounted file 
systems in the file /etc/mtab. If no arguments are given to mount, this 
list is printed. 

When the proc filesystem is mounted (say at /proc), the files /etc/mtab and 
/proc/mounts have very similar contents. The former has somewhat more 
information, such as the mount options used, but is not necessarily 
up-to-date (cf. the -n option below). It is possible to replace /etc/mtab 
by a symbolic link to /proc/mounts, but some information is lost that way, 
and in particular working with the loop device will be less convenient, and 
using the "user" option will fail.
====


If util-linux and/or the kernel were modified to get all the information on 
the mounts in /proc/mounts, /etc/mtab would be unnecessary. And, if 
/etc/mtab was needed by something, a symbolic link could be created for 
backward compatibility.

For other programs that write data to /etc, the Filesystem Hierarchy 
Standard states that variable state information should be stored in 
/var/lib.  While I don't agree with some parts of the FHS, I do think 
putting variable state information in /var/lib is a good idea.  If all 
run-time variable data and variable state information is stored as 
described in the FHS, administrators can better safe-guard the integrity of 
applications and data by mounting all file systems readonly  --- except for 
those that must be writable (/var, /home, etc.).


--
[EMAIL PROTECTED] mailing list

Reply via email to