Subject: permission() operating on inode instead of dentry?
From: Shaya Potter <spotter@cs.columbia.edu>
To: linux-kernel@vger.kernel.org
Content-Type: text/plain
Organization: 
Message-Id: <1054099180.6942.71.camel@zaphod>
Mime-Version: 1.0
Date: 28 May 2003 01:19:40 -0400
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1362
Lines: 33

[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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/