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.c1023 tcontext=unconfined_u:unconfined_r:useradd_t:s0-s0:c0.c1023 tclass=capability permissive=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.
Here's an update that adds the "permissive=0" case.
