Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> SEPostgres seems qualitatively different to me, though. I think PG
>> people have avoided reviewing it because (a) they weren't interested in
>> it and (b) they knew they were unqualified to review it.
>>
>> Meanwhile it's emerging that the selinux people don't feel qualified to
>> review it either. I'm not quite sure what to do about that. But "throw
>> it in there on faith" doesn't sound like an appealing answer, and I've
>> got no idea how long it will take to work out a non-faith-based answer.
>
> Erm, I have to say here that this strikes me as rather unfair. Perhaps
> I'm wrong, but I suspect KaiGai feels pretty good about the patch and
> his qualifications in both the PG realm and the SELinux realm. He's
Not only that but he's had many discussions with us about sepostgres, from the
security model to his reimplementation of the access vector cache. Just because
we haven't been on this list doesn't mean we haven't been watching the work.
> asking the PG folks to review it because that's the process that the PG
> community (through the CommitFest, etc) has laid out for getting a patch
> included upstream. I'm confident KaiGai isn't going to just disappear
> into the ether if the patch is committed.
>
He hasn't disappeared yet, that is probably a good sign :)
> Sure, it'd be nice if 4 or 5 other SELinux developers got in and
> understood the PG code well enough to implement such a patch, but I
We aren't a huge community and because of the nature of SELinux we have people
spread out over many different projects (X, dbus, NFS, distributions,
ipsec/networking, solaris fmac), etc. I'm probably more familiar with databases
than the others so I'm here to help (though my time is also spread over many
other things).
> think the combination of KaiGai (overall), a seperate SELinux hacker
> (for the security design and SELinux side of it), and a PG committer
> (for where the hooks are placed and how), reviewing the patch and being
> comfortable with it is quite sufficient for a high quality result.
That is all I asked for. No matter how familiar I become with the pgsql code
I'll never be as qualified as you guys for identifying security hook call sites
that are missing/misplaced. Assuming I think the security backend is correct
then it shouldn't be hard for you guys to look at the docs, see that permissions
x, y and z are required for operation foo, and know where the possible codepaths
for operation foo are and check that the hooks for x, y and z are called.