Re: [v9.2] Add GUC sepgsql.client_label
От | Kohei KaiGai |
---|---|
Тема | Re: [v9.2] Add GUC sepgsql.client_label |
Дата | |
Msg-id | CADyhKSWRVVvfwCdHOV+980bwcZ24AMvmqfTqZbpNUONiVLPx_g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [v9.2] Add GUC sepgsql.client_label (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [v9.2] Add GUC sepgsql.client_label
|
Список | pgsql-hackers |
2012/3/12 Robert Haas <robertmhaas@gmail.com>: > On Mon, Mar 12, 2012 at 10:58 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: >> It is a practical reason. In case when httpd open the connection to PG and >> set a suitable security label according to the given credential prior to launch >> of user application, then keep this connection for upcoming request, it is >> worthwhile to reset security label of the client. > > But wait a minute - how is that any good? That allows the client to > pretty trivially circumvent the security restriction that we were > trying to impose by doing sepgsql_setcon() in the first place. It > doesn't matter how convenient it is if it's flagrantly insecure. > > Am I missing something here? > It is a practical reason. If we would not support the reset feature, the application has to know the security label of itself, as a target label to be reverted. However, I'm not certain the status of script- language binding of libselinux feature to obtain the self label, although it is supported on Perl, Ruby and PHP (with extension by myself) at least. It seems to me a reasonable cost to track the original label to eliminate a restriction of application side that tries to revert the security label once switched. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: