Re: rest of works for security providers in v9.1

(2010/12/14 10:41), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei<kaigai@ak.jp.nec.com>:
>>>> I counted number of lines of the sepgsql module that implement
>>>> only currently supported hooks. It has 3.2KL of code not.
>>>
>>> Uh, wow.  That's rather surprising.  I thought that it would be
>>> measured in hundreds of lines.  Aren't the hooks that we implemented a
>>> pretty close match for what SE-Linux needs?  What is all that code
>>> doing?
>>>
>> The hooks are deployed well suitable for SE-Linux needs.
>> Because a certain amount of codes are necessary to communicate between
>> kernel and application using right security labels, the fist meaningful
>> stuff requires this size.
>>
>> See below,
>>
>> [kaigai@saba sepgsql]$ wc -l *
>>   337 dml.c
>>   222 hooks.c
>>   132 initdb.sepgsql.in
>>   710 label.c
>>    40 language.c
>>    40 largeobject.c
>>    28 Makefile
>>    70 proc.c
>>   141 relation.c
>>    40 schema.c
>>   740 selinux.c
>>   311 sepgsql.h
>>   465 uavc.c
>>   3276 total
>>
>> The largest selinux.c is the routine to communicate between user-space and
>> kernel-space using libselinux. The second largest label.c is the routine to
>> validate security label and to assign initial security labels. The third
>> largest uavc.c is a facility to cache access control decision recently used.
>> The uavc.c might be stripped out for the first version.
>> The dml.c is as a literal. The hooks.c is entrypoints of hooks.
> 
> Hmm.  So when you say 3200 lines of code, you're not counting
> documentation, which you definitely need.
> 
Yes, I'll need to add documentation and test cases from now, in addition
to the code itself.

> I'd say post what you have and I'll look it over and give feedback.  I
> am not too keen on stripping out the caching mechanism.  I'm not sure
> that's going to do much to simplify the patch. but I'm pretty sure it
> will make it a lot less useful.
> 
The starter version is not intended to use in production system, so
I'm optimistic even if caching mechanism is stripped out at first.
I believe raw-query to SE-Linux can be easily replaced by the cached-
query in the future. (In fact, I switched it before.)

Although the scale is not so large, implementations of post creation
hooks for language and largeobject can be stripped out, because we
don't have any hooks to apply access controls on these objects, so
labels of these objects are nonsense right now.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>