If /etc/mtab is a non writeable symlink (e.g. to /proc/mounts) then /etc/init.d/mtab intentionally skips mtab update. However the test for a non writeable symlink is actually broken: 15 # /etc/mtab could be a symlink to /proc/mounts 16 if [ ! -w /etc/mtab -a -L /etc/mtab ]; then 17 eeinfo "Skipping mtab update (non writeable symlink)" 18 return 0 19 fi The bug is "! -w /etc/mtab", which returns FALSE when run by root, regardless of the write permission bits in the symlink destination file. This is because test(1) considers all files to be writeable by root. Here is a trivial demonstration: # touch /tmp/fred # chmod 0 /tmp/fred # ls -l /tmp/fred ---------- 1 root root 0 Jun 4 13:13 /tmp/fred # if [ -w /tmp/fred ]; then echo /tmp/fred is writeable; fi /tmp/fred is writeable # Thus /etc/init.d/mtab does not detect that /etc/mtab is a non writeable symlink. Reproducible: Always Steps to Reproduce: 1. login as root 2. rm /etc/mtab 3. ln -s /proc/mounts /etc/mtab 4. if [ ! -w /etc/mtab -a -L /etc/mtab ]; then echo /etc/mtab is a non writeable symlink; fi Actual Results: No message is echoed. Expected Results: The message "/etc/mtab is a non writeable symlink" should be echoed, since /etc/mtab is indeed a non writeable symlink.
it isnt so much that test considers all files writable, it's that linux does. touch foo chmod 0 foo echo asdf > foo cat foo the -L test along isnt sufficient and is the reason we added -w in the first place. if /etc/mtab is a symlink to say /var/run/mtab, then we need to still update it like normal.
*** Bug 373425 has been marked as a duplicate of this bug. ***
Created attachment 280783 [details] 0001-mtab-fix-test-for-proc-mounts.patch All, here is a proposed fix for this issue. Since this script is running as root, using "! -w" in the test is moot, so I think we should just test to see if the target of the symbolic link is "/proc/mounts". What do you think?
This is fixed in commit 863ef36.
Comment on attachment 280783 [details] 0001-mtab-fix-test-for-proc-mounts.patch the -L test is redundant. if /etc/mtab isn't a symlink, then it'll simply return /etc/mtab which means it won't be equal to /proc/mounts and the code won't return early on.
mount and umount always create a regular file at /etc/mtab, never a symlink. So my feeling is that if /etc/mtab is found to be a symlink then it must have been created by some other mechanism (system administrator ?) and openrc should leave it alone, regardless of where it's pointing to.
Created attachment 283597 [details] fix-mtab.patch This patch modifies the test to return if /etc/mtab is a symbolic link, regardless of where it points. Is this the way we want to fix this bug? If there are no objections I will make this change.
(In reply to comment #7) i dont think we want to go this route. the code (iirc) was introduced because people were storing mtab in /var and their / (and /etc) were readonly. i think the existing readlink test is fine i re-opened this bug as there wasnt a response on my previous comment, but i see current openrc code dropped the -L test.
As far as I can see, /bin/mount does not modify /etc/mtab if it is a symlink: # ls -l /etc/mtab lrwxrwxrwx 1 root root 9 Aug 17 12:12 /etc/mtab -> /tmp/mtab # cat /etc/mtab rootfs / rootfs rw 0 0 /dev/root / jfs rw,noatime,nodiratime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 rc-svcdir /lib64/rc/init.d tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 udev /dev tmpfs rw,nosuid,relatime,size=10240k,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0 shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0 /dev/sda1 /boot jfs rw,noatime,nodiratime 0 0 /dev/sda4 /home jfs rw,noatime,nodiratime 0 0 # ls /mnt/root32 # mount /mnt/root32 # cat /etc/mtab rootfs / rootfs rw 0 0 /dev/root / jfs rw,noatime,nodiratime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 rc-svcdir /lib64/rc/init.d tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 udev /dev tmpfs rw,nosuid,relatime,size=10240k,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0 shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0 /dev/sda1 /boot jfs rw,noatime,nodiratime 0 0 /dev/sda4 /home jfs rw,noatime,nodiratime 0 0 # ls /mnt/root32 bin boot dev etc home lib mnt opt proc root sbin sys tmp usr var # umount /mnt/root32 # cat /etc/mtab rootfs / rootfs rw 0 0 /dev/root / jfs rw,noatime,nodiratime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 rc-svcdir /lib64/rc/init.d tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 udev /dev tmpfs rw,nosuid,relatime,size=10240k,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0 shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0 /dev/sda1 /boot jfs rw,noatime,nodiratime 0 0 /dev/sda4 /home jfs rw,noatime,nodiratime 0 0 # ls /mnt/root32 # An examination of the source for /bin/mount (util-linux-2.19.1) seems to show why: util-linux-2.19.1/mount/fstab.c: 65 mtab_is_writable() { 66 int fd; 67 68 /* Should we write to /etc/mtab upon an update? 69 Probably not if it is a symlink to /proc/mounts, since that 70 would create a file /proc/mounts in case the proc filesystem 71 is not mounted. */ 72 if (mtab_is_a_symlink()) 73 return 0; 74 75 fd = open(_PATH_MOUNTED, O_RDWR | O_CREAT, 0644); 76 if (fd >= 0) { 77 close(fd); 78 return 1; 79 } else 80 return 0; 81 } ... 869 void 870 update_mtab (const char *dir, struct my_mntent *instead) { 871 mntFILE *mfp, *mftmp; 872 const char *fnam = _PATH_MOUNTED; 873 struct mntentchn mtabhead; /* dummy */ 874 struct mntentchn *mc, *mc0 = NULL, *absent = NULL; 875 struct stat sbuf; 876 int fd; 877 878 if (mtab_does_not_exist() || !mtab_is_writable()) 879 return; 880 Thus /bin/mount considers /etc/mtab to be read-only if it is a symlink. Why shouldn't openrc do likewise? A simple test for a symlink, regardless of where it points to, should be fine.
*shrug* maybe i remember wrong. the symlink logic in util-linux does seem to date back past 2003. William: we'll want to merge your latest "fix-mtab.patch"
This has been merged in commit 2330978.