>David Wagner said:
>> 1. lsm_perror is inherently thread-unsafe (in contrast to perror).
>
>Why? sed 's/perror/lsm_perror/g' < perror.c > lsm_perror.c
I think there's a fundamental misunderstanding about the kernel syscall
interface, and how perror() is implemented.
When the kernel wants to return an error (EPERM), it does NOT set 'errno'.
The notion of an 'errno' global variable does not even exist in kernel
space; it is purely a fiction of the C library you happen to use.
Rather, all syscalls return an 'int', and on an error, the kernel returns
a negative number encoding the error (e.g., -EPERM). Then there's a
libc wrapper that translates this into a return value of -1 and stores
the error in 'errno'. Note that 'errno' is a global variable in each
user-level process. Thus, the libc wrapper code looks something like
this:
int fork() {
int rv = _fork();
if (rv < 0) { errno = -rv; rv = -1; }
return rv;
}
Do you understand now why perror() is fundamentally different from
lsm_perror()?
Hint: You can't stuff the lsm error information in the syscall return
value without fundamentally changing the semantics of the Linux syscall
API.
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Apr 23 2001 - 19:50:55 PDT