On Wed, Jan 28, 2015 at 10:06 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > 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? Indeed. On the other hand, it's not like an S_IMMUTABLE user on a local FS couldn't bypass it by mounting with a hacked filesystem, and that's sort of analogous to the protection you'd get by not offering up write caps to anybody. Anything more extreme would require OSD-side protections, which is a research topic I'm interested in but not anything we have a near-term solution for.... ;) -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
