I built and tested orangefs-untested ... Orangefs still seems to work OK... I built it as a module and didn't trigger the BUG_ON when I unloaded it. -Mike On Fri, Jan 22, 2016 at 3:51 PM, Mike Marshall <hubcap@xxxxxxxxxxxx> wrote: > 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
