lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 20 Feb 2017 20:07:53 -0800 From: James Bottomley <James.Bottomley@...senPartnership.com> To: "J. R. Okajima" <hooanon05g@...il.com> Cc: Djalal Harouni <tixxdz@...il.com>, Chris Mason <clm@...com>, Theodore Tso <tytso@....edu>, Josh Triplett <josh@...htriplett.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, Andy Lutomirski <luto@...nel.org>, Seth Forshee <seth.forshee@...onical.com>, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org, Dongsu Park <dongsu@...ocode.com>, David Herrmann <dh.herrmann@...glemail.com>, Miklos Szeredi <mszeredi@...hat.com>, Alban Crequy <alban.crequy@...il.com>, Al Viro <viro@...IV.linux.org.uk>, "Serge E. Hallyn" <serge@...lyn.com>, Phil Estes <estesp@...il.com> Subject: Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount On Tue, 2017-02-21 at 11:57 +0900, J. R. Okajima wrote: > James Bottomley: > > I realised as I was trimming down the vestigial inode properties in > > the patch that actually shiftfs does use the i_ino from the > > underlying for userspace. The reason why is that it comes from the > > getattr call in stat and that's fully what the underlying > > filesystem returns (including the inode number). > > Let me make sure. > - shiftfs has its own inode, but it will never be visible to > userspace. - the inode attr visible to users are equivalent to the > underlying one, includeing dev:ino pair. > right? Yes, it behaves like a bind mount. > If so, I am afraid it will make users confused. The dev:ino pair is a > system-wide identity, I don't believe it will, otherwise they'd have the same confusion over a real bind mount. The dev:inum pair identifies an inode. An inode may have many paths and shiftfs just adds a path. > but shiftfs creates the same dev:ino pair with different owner. With a different owner view, but that's irrelevant to the underlying inode. > Though I don't know whether the actual application or LSM exists or > not who will be damaged by this situation. > For git-status case which I wrote previously, it might not be a > problem as long as dev:ino is unchanged from git index. > But such filesystem looks weird. It behaves as much as possible like a bind mount and the user view is standard behaviour, so it can't really be classified as "weird". What won't work like a classic bind mount in this scenario is NFS exporting, but that's about the only thing. James
Powered by blists - more mailing lists