From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miklos Szeredi Subject: Re: read only bind mount ignores ready only Date: Thu, 12 Dec 2013 20:42:54 +0100 Message-ID: References: <52A878C5.6050505@ubuntu.com> <20131212120544.GJ16572@x2.net.home> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Phillip Susi , util-linux@vger.kernel.org, Linux-Fsdevel To: Karel Zak Return-path: Received: from mail-qe0-f41.google.com ([209.85.128.41]:60977 "EHLO mail-qe0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751606Ab3LLTm5 (ORCPT ); Thu, 12 Dec 2013 14:42:57 -0500 Received: by mail-qe0-f41.google.com with SMTP id gh4so782342qeb.0 for ; Thu, 12 Dec 2013 11:42:54 -0800 (PST) In-Reply-To: <20131212120544.GJ16572@x2.net.home> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Dec 12, 2013 at 1:05 PM, Karel Zak wrote: > > [CC: kernel guys] > > On Wed, Dec 11, 2013 at 09:37:57AM -0500, Phillip Susi wrote: >> It seems that the kernel has a bug where it silently ignores the >> MS_RDONLY flag when creating a bind mount. mount issues a warning >> that the mount point appears to be read-write even though you >> requested read only. The reporter suggests a patch to automatically >> attempt to remount with MS_RDONLY before issuing this warning to work >> around the kernel bug. What do you think? > > I have it implemented, so > > mount --bind --read-only /mnt /mnt > > is interpreted as two requests (two mount(2) calls) > > mount --bind /mnt /mnt > mount -o remount,bind,ro /tmp > > it works as expected, but it does not work with MS_REC (recursive) > because kernel currently does not support > > MS_REMOUNT|MS_BIND|MS_REC|... > > it means that > > mount --rbind --read-only /mnt /mnt > > creates only top-level read-only mountpoint, the rest is unchanged. > > > Miklos would be possible to fix kernel to accept MS_REC for > MS_REMOUNT|MS_BIND|MS_RDONLY operation? Please. I really hate the current mount(2) API. It's a gigantic hack, and it's nearing the end of its life anyway due to flags running out. So instead of adding more hacks, I think it would be better to think about adding a couple of syscalls that have clearly defined semantics. Thanks, Miklos