Re: sepgsql logging

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: sepgsql logging
Дата
Msg-id 2611841.1641923743@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: sepgsql logging  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: sepgsql logging  (Dave Page <dpage@pgadmin.org>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> I am not that person either. I agree this looks reasonable, but I also
> would like the opinion of an expert, if we have one.

I'm not sure we do anymore.  Anyway, I tried this on Fedora 35 and
confirmed that it compiles and the (very tedious) test process
described in the sepgsql docs still passes.  Looking in the system's
logs, it appears that Dave didn't precisely emulate how SELinux
logs this setting, because I see messages like

Jan  4 12:25:46 nuc1 audit[1754]: AVC avc:  denied  { setgid } for  pid=1754 comm="sss_cache" capability=6
scontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023tcontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023
tclass=capabilitypermissive=0 

So it looks like their plan is to unconditionally write "permissive=0"
or "permissive=1", while Dave's patch just prints nothing in enforcing
mode.  While I can see some virtue in brevity, I think that doing
exactly what SELinux does is probably a better choice.  For one thing,
it'd remove doubt about whether one is looking at a log from a sepgsql
version that logs this or one that doesn't.

Other than that nitpick, I think we should just push this.

            regards, tom lane



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

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: Avoiding smgrimmedsync() during nbtree index builds
Следующее
От: John Naylor
Дата:
Сообщение: Re: Should we improve "PID XXXX is not a PostgreSQL server process" warning for pg_terminate_backend(<>)?