Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount

From: James Bottomley
Date: Mon Feb 20 2017 - 23:08:13 EST

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

> 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.