[rsbac] A few comments/questions on RSBAC
tvrtko.ursulin@sophos.com
tvrtko.ursulin at sophos.com
Wed Jul 6 18:22:14 CEST 2005
Hi all,
[btw, kernel 2.6.11, RSBAC 1.2.4]
I just started looking at RSBAC two days ago so excuse me if something I
say might be completely wrong.
1. There is a rsbac_kmalloc function which allocate in this way:
#if KERNEL >= 2.6
kmalloc(size, GFP_ATOMIC)
#else
kmalloc(size, GFP_KERNEL)
#endif
Why? It looks totally wrong and extremely hackish. It also leads me to
belive that request hook must not sleep, which I have confirmed with
kernel debugging options. Of course, because of that, the whole usability
is questionable.
The comment for that function is also wrong, it says that it will always
allocate GFP_KERNEL.
2. However, DAZ module which is shipped together with RSBAC does sleep in
it's request hook by waiting on a event, of course it will do that since
it must communicate with userspace.
3. DAZ subdirectory also holds two completely identical files,
dazuko_rsbac.c and dazuko_main.c. One of them is not used. There are more
unused files in there (FreeBSD?!).
4. RSBAC source code is full of enums, unions and structures named like
struct rsbac_something_t. They are not typedef-ed, so why they have _t
suffix? I thought that it is a convention that typedef-ed type should have
_t added to them and this is confusing.
Having noticed all this by only briefly looking at the code, how mature
and stable do you consider RSBAC to be currently? Especially on 2.6
kernels?
Regards,
Tvrtko
More information about the rsbac
mailing list