Re: Problems with some of the current hooks

offerat_private

* frm sdsat_private "08/06/01 09:43:14 -0400" | sed '1,$s/^/* /'
*
* 
* On Fri, 3 Aug 2001, richard offer wrote:
* 
* 
*> I'd like to suggest dropping the read/readv, write/writev hooks,
*> extending permission to cope with being called from
*> read/readv/write/writev/pread/pwrite (with enough information for the
*> module to determine where it is called from), Then having separate hooks
*> for sendfile and readdir.
* 
* I'm not sure what you mean by "with enough information for the
* module to determine where it is called from."  Currently, the
* file_ops->permission hook does pass a flag indicating whether
* it is a read or write operation.  Why would you want to know
* specifically whether it is a read vs. readv vs. pread?  

So that I can decipher the arguments appropriately. For pread we're going
to have to pass the offset, for readv the iovec

And we still have to get fds in there, we need them. 

* And
* why exactly do you want separate hooks for readdir and sendfile?

Because they have different enough APIs and usages that I think it would be
worth it. Otherwise the general purpose hook is going to have too many
parameters.

* The file_ops->permission hook can check the inode mode to see
* if the object is a directory, if you want that distinction.  

I don't want readdir() to go through the same hook as read(), because it
did we had to implement that ugly hack of passing LSM_NOFD_AVAILABLE, when
we didn't even want a hook there in the first place.

* And
* I'm not sure what kind of distinction you are seeking in sendfile,
* although I guess it might be nice to have a single hook call
* there instead of two separate calls.

You're passing different parameters (two fds/file structs). Why complicate
the API by trying to force it into the permission hook ?

* 

-----------------------------------------------------------------------
Richard Offer                     Technical Lead, Trust Technology, SGI
"Specialization is for insects"
_______________________________________________________________________

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module