On Thu, Oct 17, 2002 at 07:58:38PM +0100, Christoph Hellwig wrote:
> On Thu, Oct 17, 2002 at 11:53:52AM -0700, Greg KH wrote:
> > No, don't remove this!
>
> > Yes, it's a big switch, but what do you propose otherwise? SELinux
> > would need a _lot_ of different security calls, which would be fine, but
> > we don't want to force every security module to try to go through the
> > process of getting their own syscalls.
>
> They should register their syscalls with the kernel properly. Look
> at what e.g. the streams people did after the sys_call_table
> removal. It's enough that IRIX suffers from the syssgi syndrome, no
> need to copy redo their mistakes in Linux.
Hm, as I'm not a SELinux developer, I can't tell you how many different
syscalls they need, or what they are for, sorry.
But this will require every security module project to petition for a
syscall, which would be a pain, and is the whole point of having this
sys_security call.
> > And other subsystems in the kernel do the same thing with their syscall,
> > like networking, so there is a past history of this usage.
>
> But they don't allow any random module to implement it. And anyone
> asked today says the horrible sys_Scoketcall and sys_ipc cludges
> were a mistake.
How would they be done differently now? Multiple different syscalls?
I do know that Dave Miller has also complained about the sys_security
call in the past, and the difficulties along the same lines as the
ioctl 32bit problem. If we were to go to individual syscalls for every
security function, this would go away.
In the end, it's Linus's call.
thanks,
greg k-h
p.s. you might want to copy the lsm mailing list in your messages, so
those people there are aware of your comments.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:36 EST