Re: Audit patch split into 5 parts

gregat_private

Real quick response, I'm at OLS this week, so email will be infrequent.

Thanks for splitting up the patches, it helps a lot.

On Tue, Jul 24, 2001 at 04:01:24PM -0700, richard offer wrote:
> sgi-1-add-fds
> =============
> 
> Add an fd to the file_ops prototypes. 
> 
> Not receive(), I haven't had chance to look at this yet, but in previous
> audit code we don't use it. However for MAC we may need an fd. The problem
> is that at the time receive() is called there is no fd available. 
> 
> I'd like to register a XmNnotQuiteSureWhatToDoHere callback :-)

Bleah.  Personally I still do not want fds in the lsm patch for phase 1.
I'm still not convinced that anyone except audit needs this.  Even so,
that LSM_NOFD_AVAILABLE macro is hideous and isn't the answer for your
problem for is you don't have a fd at the time.

> sgi-2-post-hooks
> ================
> 
> Add an error code to the post_* hooks (change the prototypes). Always call
> the post_* hooks even if there isn't an error.

Does anyone except audit need this?

> sgi-3-misc
> ==========
> 
> Other changes that didn't fit into any of the above, change the prototype
> of ptrace/setnice/setcapability to include more information.

Doesn't apply cleanly if the other patches are not applied.  Does anyone
who understands ptrace well want to verify that the macro change is ok?
ptrace is not my strong point :)

> sgi-4-mac-before-dac
> ====================
> 
> Try and call a hook before any other DAC logic (including calls to
> capable()).

I'll let the other groups fight this one out.  I don't really care
either way, but others do.

> sgi-5-truncate
> ==============
> 
> A separate patch since I'm not sure about this, what with all the inode vs
> name discussion. We really want the name, the truncate() hook is passed an
> inode. We've added the name as well, but this is api sticks out like a sore
> thumb. It would be nice if we could come up with a generic solution for the
> all of the inode hooks, and just happen to fix this one at the same time...

I agree with Seth, this patch seems totally unnecessary.  Please explain
why you wanted to add this one.

So in short, nothing applied.

thanks,

greg k-h

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