[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
On Wed, May 28, 2003 at 01:19:40AM -0400, Shaya Potter wrote:
> [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.
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"
On Wed, 2003-05-28 at 01:48, [email protected]
wrote:
> On Wed, May 28, 2003 at 01:19:40AM -0400, Shaya Potter wrote:
> > [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.
>
> 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.
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