Re: Including STRTOK_R in a LSM

["Z. Cliffe Schreuders" <c.schreuders@murdoch.edu.au>]

Casey Schaufler wrote:
> --- "Z. Cliffe Schreuders" <c.schreuders@murdoch.edu.au> wrote:
>
>   
>> What I need is to ignore double delimiters such as (::). This can be 
>> done trivially with a string comparison to check for "\0". What I want 
>> to know is if it is ok to include the strtok_r code in my security 
>> module, or if strtok was removed for a very good reason. I am porting a 
>> lot of existing code which already uses strtok_r to a kernel security 
>> module.
>>     
>
> All over the Linux world little red flags are popping up.
>
> Text processing of the sort that requires token parsing is rare
> in the kinds of things the kernel is usually called upon to do.
> You did mention, and someone else demonstrated, that there are
> existing alternatives that you could adopt. Cluttering the kernel
> with duplicate functionality is strongly discouraged.
>   
Thanks Casey,

I plan to pass simple lines of policy from user-space into kernel 
functions which use this information to build the internal 
representation of policy.
I had started writing these functions in user-space (to save time :\) 
and stupidly did not check that strtok_r was available from within the 
kernel (I thought string.h would include it). Anyway, so now I have a 
rewrite on my hands (unless I just include the strtok_r code). All part 
of the learning process I guess.
> As far as porting existing code into the kernel goes, be sure to
> have a look at the official coding style before you show what you've
> done to anyone. 
Will do.
> If you're porting "a lot" of code (Use SELinux as a
> benchmark for an LSM. If you're bigger than that you have "a lot"
> of code) you may also be putting too much into the kernel. 
It is not a lot in comparison to SELinux.

Thanks,

Cliffe.