Summary: | sys-apps/openrc: /etc/init.d/mtab does not detect /etc/mtab symlink correctly | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | junkmailnotread |
Component: | OpenRC | Assignee: | OpenRC Team <openrc> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugs.gentoo.org.list |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 374183 | ||
Attachments: |
0001-mtab-fix-test-for-proc-mounts.patch
fix-mtab.patch |
Description
junkmailnotread
2011-06-04 12:22:15 UTC
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. |