Re: security labels on databases are bad for dump & restore

Поиск
Список
Период
Сортировка
От Kouhei Kaigai
Тема Re: security labels on databases are bad for dump & restore
Дата
Msg-id 9A28C8860F777E439AA12E8AEA7694F801116184@BPXM15GP.gisp.nec.co.jp
обсуждение исходный текст
Ответ на Re: security labels on databases are bad for dump & restore  (Ted Toth <txtoth@gmail.com>)
Список pgsql-hackers
> That doesn't answer my question. I'm talking about a client and server
> running on the same system with SELinux MLS policy so that getpeercon
> will return the context of the client process unless it has explicitly
> sets the socket create context . So again will postgresql if the
> sepgsql module is loaded call a function in sepgsql to compute the
> access vector for the source (getpeercon label) contexts access to the
> target context (tables context set by SECURITY LABEL) and fail the
> operation generating an AVC if access is denied because there is no
> policy?
>
Yes. You may see AVC denial/allowed message on PostgreSQL log, like:

LOG:  SELinux: allowed { create } scontext=unconfined_u:unconfined_r:unconfined_t:s0
tcontext=unconfined_u:object_r:sepgsql_table_t:s0tclass=db_table name="regtest_schema.regtest_table"
 

scontext comes from getpeercon(3),
tcontext comes from the configuration by SECURITY LABEL command.

Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: creating extension including dependencies
Следующее
От: Noah Misch
Дата:
Сообщение: Re: TABLESAMPLE patch is really in pretty sad shape