On Wed, 28 Jan 2015, John Spray wrote: > On Wed, Jan 28, 2015 at 5:23 PM, Gregory Farnum <[email protected]> wrote: > > My concern is whether we as the FS are responsible for doing anything > > more than storing and returning that immutable flag ? are we supposed > > to block writes to anything that has it set? That could be much > > trickier... > > The VFS layer is checking the flag for us, but some filesystems do > have paths where they need to do their own too (e.g. XFS has various > ioctls that do explicit checks too). It's also up to us to publish > the S_IMMUTABLE bit to the i_flags attribute of the generic inode, > based on wherever/however we store the flag ourselves. > > Fuse doesn't seem to have a path for us to update i_flags though, so > it might be that we either have to extend that interface or do the > checking ourselves in userspace in order to support it there.
It seems like we should be checking S_IMMUTABLE in the MDS and, when set, refusing to issue write caps. We probably also need a check in the clients so that they return EROFS (I assume?) instead of waiting for said caps... In any case, I don't think relying on clients to cooperate is quite the level protection S_IMMUTABLE users are looking for? sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
