permission() operating on inode instead of dentry?

[please cc: responses to me, have 10k message backlog in l-k folder)

Is there a good reason why the fs permission function operates on the inode instead of the dentry? It would seem if the dentry was passed into the function instead of the inode, one would have a better structure to play with, such as being able to use d_put() to get the real path name. The inode is still readily accessible from the dentry.

in fact that std case seems to be (from sys_truncate)

pathwalk to get nameidata, this gives us dentry, this gives us inode, test permissions on inode.

If permission took the dentry, I could easily extend it to have an out of filesystem permission scheme that worked on a file's path without serious surgery on the kernel (think SubDomain) as well as being very low overhead (just d_put() the path inside the perm function and go from there)

anyways, just wondering if there's a reason I'm not thinking of for why it needs to operate on the inode directly, and if I'm not missing anything if there's any chance that a patch would be accepted to make it operate on the dentry instead?

thanks,

shaya

man grep.

Then use the resulting knowledge to find the callers of said function in the tree.

Then think where you would get dentry (and vfsmount, since you want path) for each of these. Exclude ones that have them available. See which functions contain the rest of calls.

Repeat the entire thing for each of these functions, until the set is empty. At that point you have a sequence of changes that need to be done. Start moving from the end of list, changing the prototypes and updating callers. You will get a sequence of patches ending with what you want. Look at their sizes. If they are tolerably small and straightforward - start posting them to fsdevel, one by one. With summaries. Start with posting the list of changes (step 1 propagates ..., step 2..., step n gives what we want).

Get that stuff merged, one by one. Since it won't go in one release, repeat the searches to verify that your analysis is still correct and no new paths had appeared.

That's how it's done - there's nothing more to it. And yes, this one will end up in a moderately long chain of patches - it appeared to be doable the last time I'd looked, but would result in 10-15 steps _if_ nothing tricky would crop up.

I'm going to assume this mean "it's a reasonable idea, all that matters is the execution"

Why would the calling process not be the right place? Everything should have a calling process, or am I missing something?

<snipped how to get it done>

thanks,

shaya