Re: Updates of SE-PostgreSQL 8.4devel patches (r1324) - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: Updates of SE-PostgreSQL 8.4devel patches (r1324)
Date
Msg-id 494AE286.40701@kaigai.gr.jp
Whole thread Raw
In response to Re: Updates of SE-PostgreSQL 8.4devel patches (r1324)  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Updates of SE-PostgreSQL 8.4devel patches (r1324)  (Bruce Momjian <bruce@momjian.us>)
Re: Updates of SE-PostgreSQL 8.4devel patches (r1324)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Bruce Momjian wrote:
> KaiGai Kohei wrote:
>> Bruce Momjian wrote:
>>> KaiGai Kohei wrote:
>>>> - Two new system columns ("security_acl" and "security_label") are added.
>>>>   The first one is for the Row-level ACLs, and the other is for the guest
>>>>   of PGACE security framework which is chosen by user.
>>> This is certainly an impressive patch.  I see you went with storing the
>>> values inline rather than using pg_security, which is wise, I think.
>>> "security_acl" is 'aclitem' (12 bytes) and "security_label" is 'text'.
>> No, the "security_acl" also uses pg_security to translate between
>> security id (4bytes) and "aclitem[]" (variable length).
>>
>> The Row-level ACLs facility internally translate the given acl array
>> into its own text representation, and stores it within pg_security.
>> We can use a common facility here to manage both of "acl" and "label".
> 
> OK, then I am confused.  I see this added to
> src/include/catalog/pg_attribute.h:
> 
> + DATA(insert ( 1247 security_acl   1034 0 -1  -8 1 -1 -1 f x i t f f t 0));
> + DATA(insert ( 1247 security_label   25 0 -1  -9 0 -1 -1 f x i t f f t 0));
> 
> 1034 and 25 are the oids for 'acllist' and 'text' and they are being
> added to system tables.  Are you saying system tables don't use
> pg_security but other tables do?

It means users can refer the "security_acl" and "security_label",
as if they have proper types. However, in actually, they are stroed
as security identifiers.

When user refers "security_acl", the patched heap_getsysattr() invokes
rowaclHeapGetSecurityAclSysattr() to translate the security identifier
of Row-level ACLs into an array of ACLs. User will see the translated
representation, as if there is a variable length array, not an oid.

The rowaclHeapGetSecurityAclSysattr() fetch a tuple for the given
security identifier from pg_security. It contains a text representation
of ACLs, so the function exchange it into Acl *.

rowaclHeapGetSecurityAclSysattr() -> rowaclSidToSecurityAcl()     -> pgaceLookupSecurityLabel() ... It fetch a tuple
frompg_security     -> rawAclTextToAclArray() ... It translate from TEXT -> AclItem[]
 

> I do see pg_security being defined:
> 
>     + CATALOG(pg_security,3400) BKI_SHARED_RELATION
>     + {
>     +   text        seclabel;       /* text representation of security label */
>     + } FormData_pg_security;
> 
> and I assume both security columns reference that.

Yes, AclItem[] is internally translated into text representation to store
it on pg_security.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches (r1324)
Next
From: Bruce Momjian
Date:
Subject: Re: Summary: changes needed in function defaults behavior