Nope... I guess that's why the original developer called copy_attributes_to_inode every time... I need to at least check permissions... if a file's permissions change via an external source, say from 755 to 700, the other guy can still cat the file once... -Mike On Fri, Jan 22, 2016 at 3:04 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, Jan 22, 2016 at 02:21:44PM -0500, Mike Marshall wrote: >> Al... >> >> I think that my commit f987f4c28 >> "don't trigger copy_attributes_to_inode from d_revalidate." >> doesn't really do the job... I think I at least need to >> write code that checks some of the attributes and >> fails the revalidate if they got changed via some >> external process... does that sound right? > > Won't your orangefs_revalidate_lookup() spot the changed handle? Anyway, > some sanity checks in there might be a good idea - at least "has the > object type somehow changed without handle going stale?"... > > Said that, what should be picking e.g. chmod/chown by external source? > You don't have ->permission() instances in there, so inode->i_mode is > used directly by generic_inode_permission()... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
