Re: 8.4 release planning - Mailing list pgsql-hackers

Tom Lane wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> It seems to me that there are two different standards to which this feature
>> might be held.
> 
>> Is the goal
>>   a) SEPostgres can provide useful rules to add security to some
>>      specific applications so long as you're careful to avoid crafting
>>      policies that produce bizarre behaviors (like avoiding restricing
>>      access to foreign key data you might need).   On the other hand it
>>      gives you enough rope to hang yourself and produce weird results
>>      that don't make sense from a SQL standard point of view if you
>>      aren't careful matching the SEPostgres rules with your apps.
> 
>> or
>>   b) SEPostgreSQL should only give enough rope that you can not
>>      craft rules that produce unexpected behavior from a SQL point
>>      of view; and that it would be bad if one can produce SEPostgres
>>      policies that produce unexpected SQL behavior.
> 
> With my other hat on (the red one) what I'm concerned about is whether
> this patch will ever produce a feature that I could turn on in the
> standard Red Hat/Fedora build of Postgres.  Right at the moment it seems
> that the potential performance hit, for users who are *not using*
> SEPostgres but merely have to use a build in which it is present,
> might be bad enough to guarantee that that will never happen.
> 

According to the comments in security/sepgsql/core.c:


/* * sepgsqlIsEnabled * * This function returns the state of SE-PostgreSQL when PGACE hooks * are invoked, to prevent
tocall sepgsqlXXXX() functions when * SE-PostgreSQL is disabled. * * We can config the state of SE-PostgreSQL in
$PGDATA/postgresql.conf.* The GUC option "sepostgresql" can have the following four parameter. * * - default    : It
alwaysfollows the in-kernel SELinux state. When it *                works in Enforcing mode, SE-PostgreSQL also works
in*                Enforcing mode. Changes of in-kernel state are delivered *                to userspace SE-PostgreSQL
soon,and SELinux state *                monitoring process updates it rapidly. * - enforcing  : It always works in
Enforcingmode. In-kernel SELinux *                has to be enabled. * - permissive : It always works in Permissive
mode.In-kernel SELinux *                has to be enabled. * - disabled   : It disables SE-PostgreSQL feature. It works
asif *                original PostgreSQL */
 


and in the hooks there is a pgace_feature that turns off the checks:

void
pgaceGramAlterRelation(Relation rel, HeapTuple tuple, DefElem *defel)
{        switch (pgace_feature)        {
#ifdef HAVE_SELINUX        case PGACE_FEATURE_SELINUX:                if (sepgsqlIsEnabled())                {
             sepgsqlGramAlterRelation(rel, tuple, defel);                        return;                }
break;
 
#endif        default:                break;        }
        if (defel)                ereport(ERROR,                                (errcode(ERRCODE_PGACE_ERROR),
                      errmsg("unable to set security attribute of 
 
table "                                                "via ALTER TABLE")));
}


So the pgace_feature turns off the backend call, there is an extra function 
call, and a branch but that shouldn't cause the kind of performance degradation 
you are talking about.