On Wed, 28 Jan 2015, John Spray wrote: > On Wed, Jan 28, 2015 at 5:23 PM, Gregory Farnum <greg@xxxxxxxxxxx> 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 _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |