>> The whole "early security" business looks like a mess :-(. I suspect
>> you should rip all that out of the backend and add a step to initdb
>> that fills in those tables.
>
> I also think "early security" codes are ad-hoc. :-(
> Pushing it into initdb seems me a good idea.
> I'll try to consider whether it is possible, or not.
The purpose of "early security" code is to manage relationship security
identifier and text representation before pg_security creation.
Therefore, we can make it redundant if initializing security attributes
can be done later. In the next patch set, I'll inject a hook to initialize
them at the last of bootstraping phase, and remove "early security" code.
Any tuples inserted during bootstraping mode are unlabeled, and this
operation is always allowed. Then, this hook is invoked after setting
up all system catalog, and it labels whole of database, as if "restorecon"
command initialize security context of filesystem objects.
How do you think about this design?
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
