Re: security label support, part.2
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: KaiGai Kohei <kaigai@kaigai.gr.jp>
Cc: KaiGai Kohei <kaigai@ak.jp.nec.com>, pgsql-hackers@postgresql.org
Date: 2010-07-23T13:36:52Z
Lists: pgsql-hackers
On Fri, Jul 23, 2010 at 8:59 AM, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote: > (2010/07/23 20:44), Robert Haas wrote: >> >> 2010/7/23 KaiGai Kohei<kaigai@ak.jp.nec.com>: >>>> >>>> Hmm. How about if there's just one provider loaded, you can omit it, >>>> but if you fail to specify it and there's>1 loaded, we just throw an >>>> error saying you didn't specify whose label it is. >>>> >>> Perhaps, we need to return the caller a state whether one provider >>> checked >>> the given label at least, or not. >> >> Return to the caller? This is an SQL command. You either get an >> error, or you don't. >> > Ahh, I was talked about relationship between the core PG code and ESP > module. > It means the security hook returns a state which informs the core PG code > whether one provider checked the given label, then the core PG code can > decide whether it raise an actual error to users, or not. > > In other words, I'd like to suggest the security hook which returns a tag > of ESP module, as follows: > > const char * > check_object_relabel_hook(const ObjectAddress *object, > const char *provider, > const char *seclabel); I don't think that's a very good design. What I had in mind was a simple API for security providers to register themselves (including their names), and then the core code will only call the relevant security provider. I did try to explain this in point #3 of my original review. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company