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

(2010/12/14 9:32), Robert Haas wrote:
> 2010/12/13 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>>> It is a good news for me also, because I didn't imagine SE-PostgreSQL
>>>> module getting upstreamed, even if contrib module.
>>>>
>>>> OK, I'll focus on the works to merge the starter-version of SE-PostgreSQL
>>>> as a contrib module in the last commit fest.
>>>>
>>>> Probably, I need to provide its test cases and minimum documentations
>>>> in addition to the code itself. Anything else?
>>>
>>> Extremely detailed instructions on how to test it.
>>>
>> Indeed, it will be necessary.
>>
>> Two more questions:
>> How does the contrib module behave when we try to make all the
>> contrib modules on the platform that doesn't provide libselinux?
>> One idea is to add a few checks about selinux environment in
>> the configure script.
>
> That sounds about right. Presumably, the handling would be similar to
> what we already do for sslinfo, uuid-ossp, or xml2.
>
OK, I'll follow the manner.

>> 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(at)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.

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>