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 по дате отправления: