auditdistd: Use fixed-length protocol names
AcceptedPublic
Actions

Authored by des on Sep 10 2026, 9:47 AM.

Details

Reviewers

pjd
kevans
js

Summary

All communication between auditdistd senders and receivers and
internally between auditdistd and its worker children passes through the
same pair of send / receive functions. The receive function uses
recv(2) with the MSG_WAITALL flag, which in theory means we should never
get a short read. However, when handing off a socket to a worker child,
we also pass a variable-length string identifying the type of socket
we're passing, and reading this string relies on a short read. This
used to work because the arrival of the descriptor would interrupt the
recv(2) call, but this bug was fixed when the AF_UNIX code was rewritten
a while ago and auditdistd has been broken ever since.

Fixing the length of the protocol name to four characters including the
terminating null solves the short-read bug by never requiring a short
read (nothing else in auditdistd requires one).

MFC after: 3 days
Event: EuroBSDcon DevSummit 2026

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 76737
Build 73620: arc lint + arc unit

Event Timeline

des created this revision.Sep 10 2026, 9:47 AM

Herald added a subscriber: imp. · View Herald TranscriptSep 10 2026, 9:47 AM

des requested review of this revision.Sep 10 2026, 9:47 AM

Harbormaster completed remote builds in B76737: Diff 186359.Sep 10 2026, 9:47 AM

des mentioned this in D59521: hastd: Use fixed-length protocol names.Sep 10 2026, 9:48 AM

Tested it and it works fine. Thanks des

This revision is now accepted and ready to land.Mon, Oct 5, 1:19 PM

simplify

This revision now requires review to proceed.Mon, Oct 5, 1:22 PM

Harbormaster completed remote builds in B77715: Diff 188704.Mon, Oct 5, 1:22 PM

LGTM

This revision is now accepted and ready to land.Mon, Oct 5, 1:49 PM

This may work, but it seems a little bit fragile. Would it not be more robust to omit the MSG_WAITALL for the call when recv is expecting a variable-length string?

@des what do you think of the alternate solution in D60489 ? I think it's more robust, because it doesn't require the socket names and receive buffers to be exactly matched in size.