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.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company