Re: [RFC] vfs: cleanup of permission()

[Herbert Poetzl <herbert@13thfloor.at>]

On Wed, Mar 01, 2006 at 12:28:25PM +0000, tvrtko.ursulin@sophos.com wrote:
> > On Tue, 2006-02-28 at 06:26 +0100, Herbert Poetzl wrote:
> > Hi Andrew! Christoph! Al!
> > 
> > after thinking some time about the oracle words
> > (sent in reply to previous BME submissions) we 
> > (Sam and I) came to the conclusion that it would 
> > be a good idea to remove the nameidata introduced
> > in September 2003 from the inode permission()
> > checks, so that vfs_permission() can take care
> > of them ...
> 
> Could you please provide a link to that 'previous BME submissions'?

here you go: http://lkml.org/lkml/2006/1/21/19

> Thanks.

you're welcome!

> Also, since you are modifying LSM interfaces, why not discuss it on
> the LSM mailing list?

no problem with that, will cc the lsm folks next time
(feel free to bounce the messages)

for now, here is a link to this thread:
  http://lkml.org/lkml/2006/2/28/4

> And finally, please don't remove nameidata. Modules out there depend
> on it and we at Sophos are about to release a new product which needs
> it as well. The plan was to announce the whole thing parallel with the
> release, but after spotting your post I was prompted to react ahead
> of the schedule. However, I am very busy at the moment so the actual
> announcment with full details will have to wait for a week or two.

thing is, permission() does inode based checks
and the nameidata is not even provided in most
cases, so you cannot rely on that information
anyway

it would probably be better to have some kind
of vfs_permission, which uses dentry/vfsmnt for
decisions on the vfs layer, this would also allow
to cover most of the cases where nameidata is not
available (for example the filep based stuff)

best,
Herbert

> -
> 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/