Dramatic mistake in fstab

Jack (jschmid@udallas.edu)
Sun, 27 Dec 1998 08:38:23 -0600 (CST)


This is a report of a user-error. I report it because it is so strangely
fatal, and is the kind of user-error one might want to check for in a
friendly OS. CONFIG_IDIOT_CHECK?

I had been working with some nfs things, and the init scripts I was using
did not all cooperate to actually mount the nfs. I generally don't like
resorting to root for every admin type thing, so i decided to add the user
flag to the nfs partition. This worked great, and I thought to myself,
what if there was a problem with one of the other partitions, it couldn't
hurt to make them user-mountable as well. Then I made my fatal mistake. I
made / user mountable.

My next reboot (a couple days later, strangely coinciding with the 132
release), I got /sbin/fsck: Permission denied. followed by /etc/init.d/rcS:
Permission denied. followed by a whole slew of permission denied's and an
unresponsive console. SysReq: Show Tasks showed that kswapd kflushd and
init were running, but nothing else. Frightened confused I finally got to a
prompt, checked everything, but it all seemed normal.

I finally discovered that when / was mounted implicitly everything was
fine, but once rcS called mount -o remount,rw / everything stopped. It
seems that a user mountable partition if remounted gains the flag noexec.

Anyways it's a user error, I'm sure it's even well documented, but it does
seem a bit extreme a failure and useless a behavior for the root
filesystem. I'm sure someone somewhere depends on this queer behavior, but
I do wonder if a small check, or at least a warning, might not be added to
either mount or the ext2 code.

-Jack

PS the search for TCPv4 bad checksums continues. adding novj to the ppp
options seems to have fixed the problem. Still doing more testing to ensure
that the router (the remote point of my point to point) has a bad ppp
implementation and not me. Since it has a bad finger implementation, and
ppp works fine over null modems and telnet sessions, I dare say the problem
is with the router.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/