Will mounting my disk as "ro" make it completely read-only?

Question

I've got a dualboot installation with Ubuntu 10.04 and Windows 7 Ultimate. I've got 2 drives with the following partitions set up:

500 GB drive
2 partitions:
    C:/   320GB NTFS (Has Win 7 on it)
    D:/   180GB NTFS


160 GB drive
1 main partition:
    1     160GB EXT4 (Has Ubuntu 10.04 in it)

In Ubuntu, I'm auto mounting the entire 500GB drive, using an /etc/fstab line. I've configured that line as the following:

UUID=XXXXXXXXXXXXXXXX /media/WinEmily         auto    ro,auto,user,exec 0 0

Where the UUID is the one of the 500GB drive and /media/WinEmily is my existing mount point.

Now my question is, is there any way for Ubuntu to still write to either of the partitions of the 500GB drive. I'm trying to prevent that so that it will have read access only, no matter what it tries. (Except of course unmounting and remounting with read/write access.)

Update
I'm talking about normal file operations, editing and erasing files from the file system. Not destroying the entire file system using brute force.

So is there like a command like this, that would allow writing even though it's mounted as read-only.

supersuperuserdo rm --doitanyway /media/WinEmily/file.txt

Answer 1

If you mount a filesystem read-only, there is no way to modify it through filesystem operations. Not even if you're root. If you want to perform any modification (write to a file, remove a file, change permissions, update the access time, etc.), you have to remount the file system read-write (mount -o remount,rw /dev/foo).

You can still access the underlying device and write to it. (It's a very bad idea, of course.) Disks and partitions are only accessible by root unless you've explicitly changed this (usually a bad idea too).

One thing that doesn't come up very often is that the action of mounting itself might write to the disk. This can happen even with read-only mounts for journaled filesystems: if the filesystem was not cleanly unmounted, the action of mounting the filesystem may replay the journal and perform the queued actions (it does for ext3; I don't know about ntfs). This means you can't easily inspect the disk of a suspended machine (e.g. the disk image of a paused virtual machine viewed on the host, or a hibernating system from a rescue CD).

Answer 2

"Is there a command"...well depends on how you define a command...like

#!/bin/bash (in file 'mynewcommand' set executable in your PATH)
# temp remount fs rw, execute passed in command(s), remount again, ro sudo
mount  -o remount,rw UUID=xxx   /place 
eval $1 
sudo mount -o remount,ro UUID=xxx....

Is this the type of thing you were looking for?

---

For what it's worth .. the idea that a mount might 'change' the file system applies primarily to file systems that are 'journaled' (a form of drive-format protection). NTFS is journaled on Windows. I don't believe current versions of linux have journaling in them yet. Normally replaying a journal isn't a problem unless you are doing forensics on the file system or the file system is corrupt.

Answer 3

Under normal conditions:

If you want to protect it from yourself, meaning accidental operations, this is enough.

No decent command like supersuperuserdo rm --doitanyway /media/WinEmily/file.txt can possibly cause file.txt to be deleted.

To cause damage there must be two things: sudo, and either mount -o rw or /dev/sda1.

Now, if the problem is someone else that has access to your computer, you must either trust that they won't use the words mount -o rw and /dev/sda1, or not give them an admin account in first place. With an admin account they can do whatever they want. Another level of protection in this case is to enter BIOS setup, forbid booting from CD/USB, and password-protect the BIOS setup itself.

Answer 4

Well, you can always do dd if=/dev/zero of=/dev/sda.

That will write zeros to the disk, deleting all the data.