On Thursday, November 15, 2018 9:11:36 PM EST Richard Guy Briggs wrote:
> My understanding was that CAP_AUDIT_READ was required by
everything
> that read, including unicast. That is why it checks that capability
> CAP_AUDIT_READ. Shouldn't everything reading need that capability?
No. CONTROL already did that. READ *was* only ever and still is only
for the bind function of the multicast socket.
Auditd does 2 things. It enables auditing and reads from the socket. Because
a process has CAP_AUDIT_CONTROL doesn't necessarily mean it has
CAP_AUDIT_WRITE. So, I think it would have been benificial and expected that
when CAP_AUDIT_READ was created that it also applied to the unicast socket.
One less corner case to remember. I could also envision a world where auditd
only has read capabilities and no control capabilities. That could all be
pushed off into auditctl.
-Steve