From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: BUG: Mount ignores mount options Date: Fri, 10 Aug 2018 19:28:00 -0500 Message-ID: <87bma9oigf.fsf@xmission.com> References: <20180810153902.GH21087@thunk.org> <87d0uqpba5.fsf@xmission.com> <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <22361.1533913891@warthog.procyon.org.uk> <28045.1533916438@warthog.procyon.org.uk> <20180810161400.GA627@thunk.org> Mime-Version: 1.0 Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20180810161400.GA627-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> (Theodore Y. Ts'o's message of "Fri, 10 Aug 2018 12:14:00 -0400") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apparmor-bounces-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org Sender: "AppArmor" Content-Type: text/plain; charset="us-ascii" To: "Theodore Y. Ts'o" Cc: Eric Biggers , Tetsuo Handa , David Howells , selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org, tomoyo-dev-en-5NWGOfrQmneRv+LV9MX5uooqe+aC9MnS@public.gmane.org, Paul Moore , Miklos Szeredi , Stephen Smalley , fenghua.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, apparmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org, Greg Kroah-Hartman , viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Li Zefan , Johannes Weiner , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tejun Heo , torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org IlRoZW9kb3JlIFkuIFRzJ28iIDx0eXRzb0BtaXQuZWR1PiB3cml0ZXM6Cgo+IE9uIEZyaSwgQXVn IDEwLCAyMDE4IGF0IDA0OjUzOjU4UE0gKzAxMDAsIERhdmlkIEhvd2VsbHMgd3JvdGU6Cj4+IFRo ZW9kb3JlIFkuIFRzJ28gPHR5dHNvQG1pdC5lZHU+IHdyb3RlOgo+PiAKPj4gPiBFdmVuICp3aXRo KiBmaWxlIHN5c3RlbSBzdXBwb3J0LCB0aGVyZSdzIG5vIHdheSB0b2RheSBmb3IgdGhlIFZGUyB0 bwo+PiA+IGtlZXAgdHJhY2sgb2Ygd2hldGhlciBhIHBhdGhuYW1lIHJlc29sdXRpb24gY2FtZSB0 aHJvdWdoIG9uZQo+PiA+IG1vdW50cG9pbnQgb3IgYW5vdGhlciwgc28gSSBjYW4ndCBkbyBzb21l dGhpbmcgbGlrZSB0aGlzOgo+PiAKCj4+IEhvd2V2ZXIsIHRoZSBjYXNlIGZvbGRpbmcgc3R1ZmYg LSBpcyB0aGF0IGEgc3VwZXJibG9ja2lzbSBvZiBhIG1vdW50cG9pbnRpc20/Cj4KPiBJdCdzIGEg c3VwZXJibG9jay1pc20uICBBcyBmYXIgYXMgSSBrbm93IHRoZSAqb25seSogdGhpbmcgdGhhdCB3 ZSBjYW4KPiBzdXBwb3J0IGFzIGEgbW91bnQtcG9pbnRpc20gaXMgdGhlIHJvIGZsYWcsIGFuZCB0 aGF0J3MgaGFuZGxlZCBhcyBhCj4gc3BlY2lhbCBjYXNlLCBhbmQgb25seSBpZiB0aGUgb3JpZ2lu YWwgc3VwZXJibG9jayB3YXMgbW91bnRlZAo+IHJlYWQvd3JpdGUuICBleSBUaGF0IHdhcyBteSBw b2ludDsgYXNpZGUgZnJvbSB0aGUgcm8gZmxhZywgd2UgY2FuJ3QKPiBzdXBwb3J0IGFueSBvdGhl ciBtb3VudCBvcHRpb25zIGFzIGEgcGVyLW1vdW50IHBvaW50IHRoaW5nLCBzbyB0aGUKPiBvbmx5 IHRoaW5nIHdlIGNhbiBkbyBpcyB0byBmYWlsIHRoZSBtb3VudCBpZiB0aGVyZSBhcmUgY29uZmxp Y3RpbmcKPiBtb3VudCBvcHRpb25zLiAgQW5kIEknbSBub3QgcmVhbGx5IHN1cmUgaXQgaGVscHMg dGhlIGNvbnRhaW5lciB1c2UKPiBjYXNlLCBzaW5jZSB0aGUgd2hvbGUgcG9pbnQgaXMgdGhleSB3 YW50IHRoZWlyICJndWVzdCIgdG8gYmUgYWJsZSB0bwo+IGJsaXRoZWx5IHJ1biAibW91bnQgL2Rl di9zZGExIC1vIG5veGF0dHIgL21udCIgYW5kIG5vdCB3b3JyeSBhYm91dCB0aGUKPiBmYWN0IHRo YXQgaW4gc29tZSBvdGhlciBjb250YWluZXIsIHNvbWVvbmUgaGFkIHJ1biAibW91bnQgL2Rldi9z ZGExIC1vCj4geGF0dHIgL21udCIuICBCdXQgaGF2aW5nIHRoZSBzZWNvbmQgbW91bnQgZmFpbCBi ZWNhdXNlIG9mIGNvbmZsaWN0aW5nCj4gbW91bnQgb3B0aW9uIGJyZWFrcyB0aGUgaWxsdXNpb24g dGhhdCBjb250YWluZXJzIGFyZSBmdW5jdGlvbmFsbHkgYXMKPiByaWNoIGFzIFZNJ3MuCgpUZWQg dGhpcyBpc24ndCBhYm91dCBzb21lIGNvbnRhaW5lciBjYXNlLgoKSXQgYWJvdXQgdGhlIGZhY3Qg dGhhdCBwcmFjdGljYWxseSBldmVyeSBmaWxlc3lzdGVtIGluIHRoZSBrZXJuZWwgaGFzCnRoZSBi ZWhhdmlvciBJIGhhdmUgZGVzY3JpYmVkIGFuZCBpdCBtZWFucyB0aGF0IGlmIHJvb3QgaXMgbm90 IHN1cGVyCmNhcmVmdWwgcm9vdCB3aWxsIHNob290IGhpbXNlbGYgaW4gdGhlIGZvb3Qgd2l0aCB0 aGUgc2hvdGd1biB3ZSBoYXZlCnBvaW50ZWQgdGhlcmUuCgpJdCByZWFsbHkgaXMgYWJvdXQgbG9v c2luZyBhY2xzIG9yIHNvbWUgb3RoZXIgZmlsZXN5c3RlbSBvcHRpb24uCgoKRXJpYwoKLS0gCkFw cEFybW9yIG1haWxpbmcgbGlzdApBcHBBcm1vckBsaXN0cy51YnVudHUuY29tCk1vZGlmeSBzZXR0 aW5ncyBvciB1bnN1YnNjcmliZSBhdDogaHR0cHM6Ly9saXN0cy51YnVudHUuY29tL21haWxtYW4v bGlzdGluZm8vYXBwYXJtb3IK From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Date: Fri, 10 Aug 2018 19:28:00 -0500 Subject: BUG: Mount ignores mount options In-Reply-To: <20180810161400.GA627@thunk.org> (Theodore Y. Ts'o's message of "Fri, 10 Aug 2018 12:14:00 -0400") References: <20180810153902.GH21087@thunk.org> <87d0uqpba5.fsf@xmission.com> <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <22361.1533913891@warthog.procyon.org.uk> <28045.1533916438@warthog.procyon.org.uk> <20180810161400.GA627@thunk.org> Message-ID: <87bma9oigf.fsf@xmission.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org "Theodore Y. Ts'o" writes: > On Fri, Aug 10, 2018 at 04:53:58PM +0100, David Howells wrote: >> Theodore Y. Ts'o wrote: >> >> > Even *with* file system support, there's no way today for the VFS to >> > keep track of whether a pathname resolution came through one >> > mountpoint or another, so I can't do something like this: >> >> However, the case folding stuff - is that a superblockism of a mountpointism? > > It's a superblock-ism. As far as I know the *only* thing that we can > support as a mount-pointism is the ro flag, and that's handled as a > special case, and only if the original superblock was mounted > read/write. ey That was my point; aside from the ro flag, we can't > support any other mount options as a per-mount point thing, so the > only thing we can do is to fail the mount if there are conflicting > mount options. And I'm not really sure it helps the container use > case, since the whole point is they want their "guest" to be able to > blithely run "mount /dev/sda1 -o noxattr /mnt" and not worry about the > fact that in some other container, someone had run "mount /dev/sda1 -o > xattr /mnt". But having the second mount fail because of conflicting > mount option breaks the illusion that containers are functionally as > rich as VM's. Ted this isn't about some container case. It about the fact that practically every filesystem in the kernel has the behavior I have described and it means that if root is not super careful root will shoot himself in the foot with the shotgun we have pointed there. It really is about loosing acls or some other filesystem option. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) To: "Theodore Y. Ts'o" Cc: David Howells , viro@zeniv.linux.org.uk, John Johansen , Tejun Heo , selinux@tycho.nsa.gov, Paul Moore , Li Zefan , linux-api@vger.kernel.org, apparmor@lists.ubuntu.com, Casey Schaufler , fenghua.yu@intel.com, Greg Kroah-Hartman , Eric Biggers , linux-security-module@vger.kernel.org, Tetsuo Handa , Johannes Weiner , Stephen Smalley , tomoyo-dev-en@lists.sourceforge.jp, cgroups@vger.kernel.org, torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Miklos Szeredi References: <20180810153902.GH21087@thunk.org> <87d0uqpba5.fsf@xmission.com> <153313703562.13253.5766498657900728120.stgit@warthog.procyon.org.uk> <22361.1533913891@warthog.procyon.org.uk> <28045.1533916438@warthog.procyon.org.uk> <20180810161400.GA627@thunk.org> Date: Fri, 10 Aug 2018 19:28:00 -0500 In-Reply-To: <20180810161400.GA627@thunk.org> (Theodore Y. Ts'o's message of "Fri, 10 Aug 2018 12:14:00 -0400") Message-ID: <87bma9oigf.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: BUG: Mount ignores mount options List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: "Theodore Y. Ts'o" writes: > On Fri, Aug 10, 2018 at 04:53:58PM +0100, David Howells wrote: >> Theodore Y. Ts'o wrote: >> >> > Even *with* file system support, there's no way today for the VFS to >> > keep track of whether a pathname resolution came through one >> > mountpoint or another, so I can't do something like this: >> >> However, the case folding stuff - is that a superblockism of a mountpointism? > > It's a superblock-ism. As far as I know the *only* thing that we can > support as a mount-pointism is the ro flag, and that's handled as a > special case, and only if the original superblock was mounted > read/write. ey That was my point; aside from the ro flag, we can't > support any other mount options as a per-mount point thing, so the > only thing we can do is to fail the mount if there are conflicting > mount options. And I'm not really sure it helps the container use > case, since the whole point is they want their "guest" to be able to > blithely run "mount /dev/sda1 -o noxattr /mnt" and not worry about the > fact that in some other container, someone had run "mount /dev/sda1 -o > xattr /mnt". But having the second mount fail because of conflicting > mount option breaks the illusion that containers are functionally as > rich as VM's. Ted this isn't about some container case. It about the fact that practically every filesystem in the kernel has the behavior I have described and it means that if root is not super careful root will shoot himself in the foot with the shotgun we have pointed there. It really is about loosing acls or some other filesystem option. Eric