Red Hat Bugzilla – Bug 164879
read-only mount --bind isn't read-only
Last modified: 2012-06-20 12:17:34 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.10) Gecko/20050719 Red Hat/1.0.6-1.4.1 Firefox/1.0.6 Description of problem: I wanted to bind-mount a directory read-only so that I could safely make it visible through ftp, but, alas, it isn't read-only -- it looks as though the read-only flag is ignored even though it appears in the output of "mount". Version-Release number of selected component (if applicable): kernel-2.6.9-11.EL.x86_64 How reproducible: Always Steps to Reproduce: 1. mkdir /tmp/xxx /tmp/yyy 2. mount -o ro,bind /tmp/xxx /tmp/yyy 3. touch /tmp/yyy/this-should-not-work Actual Results: The "touch" command succeeded. Expected Results: The "touch" command should have reported a read-only filesystem error. Additional info: The entry in /etc/mtab reflects the mount command I used (/tmp/xxx /tmp/yyy none ro,bind 0 0) but the entry in /proc/mounts doesn't (/dev/root /tmp/yyy ext3 rw 0 0). It has been argued in the past (bug 77962) that this is a problem with mount and that it shouldn't allow the "ro" option for mount. That's a bit of a cop-out, even though the mount(2) man page says that the mount flags are ignored (that's a paradox; MS_BIND is a mount flag and if it's not ignored then it's ignored). There is a long-standing patch at http://www.13thfloor.at/patches/ which allows read-only bind mounts and I know that this has surfaced in the kernel mailing lists several times. Notwithstanding the efforts in the man page to turn this bug into a feature, the read-only bind is very useful for exporting for ftp without running the risk of inadvertantly making it writable.
In 2003, Al Viro posted a long description of what was required to do per-mountpoint readonly correctly: http://marc.theaimsgroup.com/?l=linux-fsdevel&m=105419650921086&w=2 IIRC, Herbert Poetzl's Bind Mount Extensions patch only addresses some of Al's requirements.
The patches change VFS semantics in a way that will break existing binary kernel filesystem modules. That alone pretty much rules it out for a RHEL-4 update. Even without that, we'd need complelling justification for such a feature extension in an update release; this sort of functionality really needs sorted out upstream and merged there to be picked up in a future RHEL version.
I don't mind this being changed to an enhancement request and I don't mind it being slated for a future version (eg RHEL5) but why have you closed it WONTFIX. Doesn't that mean it's dead and buried? If that's not the case, please feel free to close it again. If not, I'd like to put this in as an enhancement request somewhere -- just don't know where to do it.
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.