Could you elaborate on why this is a sign of trouble, design wise?
Bacause if you can't even specify the data types, something
is severely wrong. It's entirely a black box.
That doesn't give it system call status.
Compare:
read(fd, buf, size)
This reads, from file descriptor FD, into BUF of
size SIZE.
with:
security(id, call, args)
???
How would you describe this in a manpage, for example?
>There is simply no way we can enfore proper portable typing by
>all these security module authors such that we can do any kind
>of proper 32-bit/64-bit syscall translation on the ports that
>need to do this.
THAT I would love to hear about. If all we have to do to save
sys_security is change its signature, that'd be great.
Well for one thing a pointer to opaque stuff can't be translated
properly. You MUST KNOW THE DATA TYPES that are being passed
into the system call to translate it properly.
Your system call, BY DESIGN, makes the data types opaque and
indeterminable.
You can only fix this by contradicting yourself. :-)
Yes, that will be wonderful. And the LSM team will be pleased to re-work
the desing when stackable file systems appear and we can take advantage
of them.
So we should just stick your crap in now right? No, that is not how
things work.
-
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/