Mount on top of / ??

[Andrew W. Gaunt]

This is a case where the tool does one thing (mounts a filesystem) and
does its well.  If its  not encumbered with a lot of safety shields and
anti-pollution devices it is more easily understood, maintained and
generally remains more 'elegant.' 

Simple tools can often be used in ways not imagined by the designer
and that's not always a bad thing. Who among us has not used a
hammer or screwdiver in ways that they were not specifically designed
for? Sometimes the results are desirable, sometimes not.

Paul Lussier wrote:

>Bill Sconce <sconce at in-spec-inc.com> writes:
>
>  
>
>>Here's a strange question, something (I hope) you've never thought
>>of doing.  A student asked me about it, and I said it's illegal.
>>But I was wrong...
>>    
>>
>
>Yup, you are, and I've mounted file systems on top of other file
>systems plenty of times, including root. Sometimes intentionally,
>others not so much :)
>
>  
>
>>What should happen (or what does happen) if you, as root,
>>
>>    # mount -t ext3 /dev/hda9 /
>>    
>>assuming, of course, that the partition /dev/hda9 exists and is
>>correctly formatted as an ext3 filesystem?
>>    
>>
>
>What *should* happen is exactly what *does* happen.  /dev/hda9 ends up
>being the file system mounted at /.
>
>  
>
>>In all three cases the system executes the command and fails to
>>complain.
>>    
>>
>
>Why should it?  What you told it to do is perfectly valid, and, as is
>traditional with most UNIX commands, there is no output if the command
>succeeds.  Check the status of $? from the shell after you execute
>that command, it's probably 0, indicating the command succeeded.
>
>  
>
>>(I'm not saying that the system is still usable afterwards, 
>>only that the command doesn't cause an error message.)
>>    
>>
>
>That's because there was no error.  You issued a command to the shell,
>which passed it along to the kernel, which executed your wishes, and
>it succeeded.  Why would you expect there to be an error upon success?
>
>  
>
>>It's not easy to undo, either - trying "umount" generates "device is
>>busy".
>>    
>>
>
>Well, of course it is, you now have *2* file systems mounted on the
>same file handle.  To issue a command of 'umount /' is going to
>confuse the kernel.  Which file handle are you asking for, the first
>or the second.  Rather, try 'umount /dev/hda9'.  I don't know if that
>will work, but I would expect it to, unless of course, you've done
>something which would keep that file handle open, like cd'ing into it.
>
>I wouldn't be surprised if it didn't work either, you're playing with
>fire here, and, as such, it's not uncommon to get burned :)
>
>  
>
>>I don't know how to explain what's happening, either to my
>>student or to myself.
>>    
>>
>
>What do you mean?  You mounted a second file system on top of a
>mountpoint (i.e. file handle) which was already in use by another file
>system.  You're now trying to unmount the *file handle*, which points
>to *two different* file systems.  It's like you walking up a table at
>Martha's after just purchasing a pint of Stout and a pint of Porter,
>and me saying, "Hey, can I have that beer please?"  Am I referring to
>the Stout, the Porter, or Both?
>
>Common sense dictates that you ask to which I'm referring and for me
>to clarify myself.  However, the OS knows nothing about common sense
>and, possibly how you, too, should interpret my request, automatically
>assumes I want both.  Well, the obvious answer here from you should
>be, 'No.' :) In the case of the OS, it's going to look at / and say,
>"Wait a minute, I've got all these processes, not the least of
>which is PID 1 (init), that are using /. I can't unmount that *now*
>you moron!"
>
>  
>
>>What do you think?
>>Is mounting on / illegal?
>>    
>>
>
>Sure, if you couldn't mount on /, you couldn't mount on /.
>
>  
>
>>Should it be?
>>    
>>
>
>Err, yes, see above...
>
>  
>
>>If it's legal is there a realistic use case?
>>    
>>
>
>Yes, every time you boot, the OS mounts a file system on /.
>
>I think, rather, what you *mean* to ask, is: "Should it be legal to
>mount 2 file systems on the same mount point?".  You might get even
>more specific and limit this question to just the / mount point, but
>then you get in to having to write more specific error-handling code
>for edge-cases.  Since it's a lot easier to write code for the general
>case, then, why not just say what's acceptable for one should be
>acceptable for all, including /?
>
>There are probably plenty of use cases for mounting multiple file
>systems on the same mount point.  For instance, suppose you have a
>mangled root file system, or even a read-only file system which
>prevents you from doing something you normally don't want to do
>(perhaps it's a security mechanism to limit the ability of someone
>who's cracked your system).  On this one occasion, you need to do
>something which is currently not possible.  But, by mounting another
>file system over that one, you now can, all without re-booting the
>system.  When you're done, you're now able to unmount the second file
>system and return the system to the state it was before.
>
>This is probably far more useful if the file system in question is
>*not* root, but, as I stated before, it's easier to do the same for
>all rather than consider all the edge cases.
>
>Hmm, actually, a legitmate use case just came to mind, though, it
>does't involve root (but, since root is "just another file system :).
>
>I often mount and unmount differnt file systems to /mnt all the time.
>Many times I'll have a CD mounted there.  Many times, when creating
>.iso images, I'll want to mount the image before burning it.  Even
>though I may have something already mounted on /mnt, I'll mount that
>image right over the existing file system mounted at /mnt to make sure
>it works correctly, or contains the right data.  When I'm done, I'll
>unmount that image, and still be able access whatever was there
>before.
>
>Sure, I could create various mount points under /mnt and mount things
>in different places, but then I waste time a) checking to see what
>mount points are there, and b) typing more than I need to.  Why waste
>time, when I can just mount something over something else that I don't
>care about at that single moment in time?  And, it's a lot more
>natural, for me anyway, to just type 'mount foo /mnt' than it is to
>type 'mount foo /mnt/foo'
>
>  
>