Re: under CONFIG_EXPERIMENTAL? (was Re: Why auditing and ACL's are important (was: audit_ids system calls))

From: James Sutherland (jas88@cam.ac.uk)
Date: Wed May 03 2000 - 16:39:56 EST


On Wed, 3 May 2000, Tigran Aivazian wrote:

> On Wed, 3 May 2000, Linda Walsh wrote:
> > Would putting all the work
> > under a config option and marking it EXPERIMENTAL make everyone
> > happy enough for this to proceed? *Please*? :-)
>
> Dear Linda,
>
> may I ask (out of curiosity) if your patch is the same as "all the work"
> you are mentioning above? From the very brief look at your patch I thought
> you provide a framework for 64bit-returning system calls (only for IA32!)
> and also add a couple of system calls to set/get audit id. Was that the
> entire infrastructure needed on kernel side or is it just the beginning
> with some more patches to follow?
>
> I am just trying to understand - because, perhaps, unwillingless to
> include your stuff is merely due to the fact that it is not complete yet
> and one (e.g. Linus) would be naturally inclined to see the whole picture
> first before having any opinion?

Linus and/or Alan have complained in the past about people submitting
enormous patches in one block, expressing a preference for getting patches
in "piecemeal". I'd tend to agree with this approach - if Linda's first
patch, just adding these hooks, can be added, tested and trusted, then
integrating and testing the rest of the audit support code will be easier.

> If that is not the case, I would be happy to have my assumptions and
> (mis)-observations corrected.
>
> I don't know about auditing implementations but if your patch was able to
> actually implement all that is necessary, it was *very* impressively
> compact :)

It looks like a pretty good implementation, IMHO. I'd have preferred
getaudit_id() to be split into two functions, one returning the uid_t
(luid), the other returning the (signed or unsigned??) long long sess_id.
Similarly, splitting setaudit_id() into audit_newsess_id() and
audit_setluid(). Is there some reason why you didn't do that, Linda??

The other potential problem is claiming interrupt 0x81 for the new 64-bit
syscall - I'd guess this SHOULD be ok, but is it??

James.

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



This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:13 EST