[TUHS] Device special files

[random832@fastmail.com (Random832)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

On Wed, Feb 7, 2018, at 17:48, Ron Natalie wrote:
> Amusingly, we still found bugs.    I was griping that people would mount 
> on just any directory on the system, the mtab wouldn’t show the absolute 
> path.    I suggested we chdir to / early on or better yet, cd to /dev.  
> That way I wouldn’t have to type /dev/ on to the device name.     I say 
> the user would have to give an absolute path anyhow since there’s 
> nothing on /dev to mount on.    Well my roommate immediately tries to 
> prove me wrong.   He tries passing various devnodes and regular files 
> that happen to sit in /dev.   Then he gets the great idea of mounting 
> on /dev/.     It works, but now we have no way to unmount it.   We had 
> to reboot the machine.    I quickly modified mount to require an EMPTY 
> directory owned by the user to be required for mounting.

Would a mknod (in the new /dev or anywhere else) to "recreate" the device file have worked? Requiring an empty directory seems a bit overkill vs simply requiring an absolute path (perhaps one that does not begin with /dev) or having the mount command calculate the absolute path.

(I'm mildly surprised that if this was in the era where . and .. were simply hardlinks created by mkdir(1), mounting on /dev/. didn't simply literally mount on /dev/. leaving /dev alone, which would have been an interesting state but wouldn't have prevented unmounting)

Why is it that umount(2) took the device special file name rather than the mount point directory name, anyway? This seems to have been fixed in NFSv2, 4.3BSD-Uwisc, and Linux, but why was it like that in the first place? It *seems* like in the V6 era code the system could have just as well checked m_inodp for a match to the directory as m_dev for the device.