[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is inability to operate with root read-only (and separate /etc, /dev, etc) a bug or design decision?

Philipp Matthias Hahn <pmhahn@debian.org> writes:

> Hi!
> On Sat, Aug 12, 2006 at 09:34:52PM +0200, Goswin von Brederlow wrote:
>> Peter Samuelson <peter@p12n.org> writes:
>> > [Goswin von Brederlow]
>> >> Instead move the things in etc that need writing to other places:
>> >> 
>> >> 1) link /etc/mtab to /proc/mounts and create a dummy /proc/mounts on /
>> >>    for when /proc isn't mounted (works with quota in current kernels).
>> >
>> > Does the wrong thing with (a) user and (b) loop mounts.  [I just tested
>> > 2.6.16-1-k7.]  /etc/mtab needs to keep enough state for umount to know
>> > (a) who mounted something, so the same user can unmount it, and (b)
>> > that a loop device was set up automatically via 'mount -o loop', rather
>> > than done separately, so that umount can 'losetup -d /dev/loopN'.  This
>> > is information which cannot, at present, be put in /proc/mounts.
>> Yes. If you need that feature help patching the kernel (like the new
>> quota support in /proc/mounts) or link it to somewhere else.
> Which doesn't work because of linux-utils-2.12r/mount/fstab.c:55
> int
> mtab_is_writable() {
> 	static int ret = -1;
> 	/* Should we write to /etc/mtab upon an update?
> 	   Probably not if it is a symlink to /proc/mounts, since that
> 	   would create a file /proc/mounts in case the proc filesystem
> 	   is not mounted. */
> 	if (mtab_is_a_symlink())
> 		return 0;
> ...
> The path to mtab is also hardcoded in
> /usr/include/paths.h:54:#define _PATH_MOUNTED   "/etc/mtab"
> which is no fun to change "on-the-fly".
> BYtE
> Philipp

A patch for this was in the BTS that would follow the symlink but not
fail if the destination is unwritable (the /proc/mounts case).

I can't believe that is still not fixed or got lost again.


Reply to: