Re: [2.6 patch] kernel/audit.c: change the exports to EXPORT_SYMBOL_GPL

On Mon, Jul 30, 2007 at 09:18:41AM -0400, Steve Grubb wrote:
On Sunday 29 July 2007 11:02:33 Adrian Bunk wrote:
They are still completely unused, but hopefully some of the theoretical
code that might use it will appear in the kernel in the near future...

Signed-off-by: Adrian Bunk <bunk@xxxxxxxxx>
Acked-by: Steve Grubb <sgrubb@xxxxxxxxxx>

I am reluctant to say that I ack this patch for a couple reasons:

1) We are talking about a basic logging facility that should be open like
printk() is.

2) There are no user space GPL restrictions to use the audit netlink API, so
why restrict who can send audit events via the in-kernel interfaces? It just
doesn't make sense to have 2 different licenses for in-kernel vs user space
audit event recording. Its the same subsystem differing only by where the
event originated.

It's a well-known fact that there are legal differences between calling
kernel services from userspace and kernel modules.

3) The API has been unrestricted for years. I don't think its a good idea to
take a basic logging API away from people that have programmed to it.

If it's such a basic API, why isn't there a single user in the kernel?

4) In the absence of the in-kernel audit logging api, people will either
create parallel infrastructure or resort to using printk. It will be
difficult for end users to correlate security events from 2 different logs.

I would support there being a mechanism for anyone who wants to reduce the
number of exported symbols for their own kernels - I believe that is the
basic problem here. But I think there are enough reasons to continue keeping
this API open and unrestricted for anyone that wants it that way.

The Linux kernel does not offer a stable kernel API for external modules.
That's a well-known fact.

-Steve

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

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

Relevant Pages

  • Re: [ANN] WiMAX stack and drivers for Intel WiMAX Link 5050
    ... Please don't build sysfs version checks into the API. ... Rationale is most systems will have a single wimax ... make sure user space stuff can detect that and fail cleanly. ... was compiled for differs from what the kernel offers. ...
    (Linux-Kernel)
  • Re: [2.6 patch] schedule obsolete OSS drivers for removal
    ... > recommend to use ALSA API directly with apps. ... At the same time the kernel API itself should be suitable to ... > I, at least, have never thought that the OSS _API_ would die. ...
    (Linux-Kernel)
  • Re: The Linux Staging tree, what it is and is not.
    ... Powerlink) driver in staging. ... BTW, the implementation does not follow the kernel style guide, because our company has its own code style guide. ... But it is no easy task to find a common API for all field busses. ... userspace solution like outlined above. ...
    (Linux-Kernel)
  • Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity
    ... If we have a possibility to remove the code from the kernel ... > Why should there be any need to put library code between the kernel API ... > if somebody wants to emulate the OSS kernel API in library level. ... We have user space solution while you insist to put this ...
    (Linux-Kernel)
  • Re: [2.6 patch] kernel/audit.c: change the exports to EXPORT_SYMBOL_GPL
    ... code that might use it will appear in the kernel in the near future... ... why restrict who can send audit events via the in-kernel interfaces? ... doesn't make sense to have 2 different licenses for in-kernel vs user space ... The API has been unrestricted for years. ...
    (Linux-Kernel)