Messages in this thread | | | From | "J. R. Okajima" <> | Subject | Re: [RFC 1/1] shiftfs: uid/gid shifting bind mount | Date | Tue, 21 Feb 2017 11:57:27 +0900 |
| |
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? If so, I am afraid it will make users confused. The dev:ino pair is a system-wide identity, but shiftfs creates the same dev:ino pair with different owner. 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.
J. R. Okajima
| |