> That's true, as far as it goes, but it prohibits anybody from wanting
> that from using it, and forces any who DON'T, to accept it.
I don't follow your argument. Let's say that my module only wants
to implement restrictive behavior on permission(). So,
the module's permission hook function might look like:
/* Module may deny permission that would be granted by kernel,
but never grants permission that would be denied by kernel. */
static int mymodule_inode_permission(struct inode *inode, int mask, int
kern_retval)
{
if (kern_retval)
/* Kernel logic denied, so we deny too. */
return kern_retval;
/* Kernel logic allowed, but we may want to deny. */
return mymodule_inode_permission_helper(inode, mask);
}
Now let's say that my module only wants to implement permissive behavior
for permission(). So the module's permission function looks like:
/* Module may grant permission that would be denied by kernel, but
never denies permission that would be granted by kernel. */
static int mymodule_inode_permission(struct inode *inode, int mask, int
kern_retval)
{
if (!kern_retval)
/* Kernel logic allowed, so we allow too. */
return 0;
/* Kernel logic denied, but we may want to allow. */
return mymodule_inode_permission_helper(inode, mask);
}
It is quite simple to write purely restrictive modules or purely
permissive modules using this interface.
--
Stephen D. Smalley, NAI Labs
ssmalleyat_private
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Jun 06 2001 - 05:51:26 PDT