fleetd #184: report member trust model #265

Closed
agent wants to merge 0 commits from worker/fleetd-184-warn-b381ee-10 into main
Member

Summary

Adds one INFO startup report for the member trust model. The report changes when memberHerdrSocket is configured.

Final startup messages

memberHerdrSocket unset

member trust model: members run as the same OS user as fleetd, not in a sandbox. A member can read any file this user can read, including SSH keys and credential stores, whatever memberCredentials says. To add a real boundary, route members to a second herdr under a different OS user with memberHerdrSocket.

memberHerdrSocket configured

member trust model: members are routed to a separate herdr through memberHerdrSocket. fleetd cannot see that herdr's uid, so confirm it runs as a different OS user before treating it as a boundary.

Tests

Ran cd fleetd && mvn clean install.

Tests run: 1264, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

Mutation proof

I changed the configured branch to emit the unset memberHerdrSocket text. mvn -Dtest=MemberTrustModelReportTest test failed as expected:

Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
MemberTrustModelReportTest.configuredMemberHerdrSocketStatesThatFleetdCannotConfirmTheBoundary:68
expected: <member trust model: members are routed to a separate herdr through memberHerdrSocket. fleetd cannot see that herdr's uid, so confirm it runs as a different OS user before treating it as a boundary.>
but was: <member trust model: members run as the same OS user as fleetd, not in a sandbox. A member can read any file this user can read, including SSH keys and credential stores, whatever memberCredentials says. To add a real boundary, route members to a second herdr under a different OS user with memberHerdrSocket.>
BUILD FAILURE

I restored the production file. git diff --exit-code -- fleetd/src/main/java/dev/ltms/fleet/Fleetd.java then returned clean against the staged final content.

Caveat

Existing HerdrPeerLauncher messages say configured memberHerdrSocket means a different OS user. fleetd cannot confirm that from the socket, so this wording can overstate the control. I did not change it because it is outside this ticket.

## Summary Adds one INFO startup report for the member trust model. The report changes when memberHerdrSocket is configured. ## Final startup messages **memberHerdrSocket unset** > member trust model: members run as the same OS user as fleetd, not in a sandbox. A member can read any file this user can read, including SSH keys and credential stores, whatever memberCredentials says. To add a real boundary, route members to a second herdr under a different OS user with memberHerdrSocket. **memberHerdrSocket configured** > member trust model: members are routed to a separate herdr through memberHerdrSocket. fleetd cannot see that herdr's uid, so confirm it runs as a different OS user before treating it as a boundary. ## Tests Ran cd fleetd && mvn clean install. Tests run: 1264, Failures: 0, Errors: 0, Skipped: 0 BUILD SUCCESS ## Mutation proof I changed the configured branch to emit the unset memberHerdrSocket text. mvn -Dtest=MemberTrustModelReportTest test failed as expected: Tests run: 2, Failures: 1, Errors: 0, Skipped: 0 MemberTrustModelReportTest.configuredMemberHerdrSocketStatesThatFleetdCannotConfirmTheBoundary:68 expected: <member trust model: members are routed to a separate herdr through memberHerdrSocket. fleetd cannot see that herdr's uid, so confirm it runs as a different OS user before treating it as a boundary.> but was: <member trust model: members run as the same OS user as fleetd, not in a sandbox. A member can read any file this user can read, including SSH keys and credential stores, whatever memberCredentials says. To add a real boundary, route members to a second herdr under a different OS user with memberHerdrSocket.> BUILD FAILURE I restored the production file. git diff --exit-code -- fleetd/src/main/java/dev/ltms/fleet/Fleetd.java then returned clean against the staged final content. ## Caveat Existing HerdrPeerLauncher messages say configured memberHerdrSocket means a different OS user. fleetd cannot confirm that from the socket, so this wording can overstate the control. I did not change it because it is outside this ticket.
agent added 1 commit 2026-09-03 11:49:18 +02:00
fleetd #184: report member trust model
CI / contract (pull_request) Successful in 53s
CI / build (pull_request) Successful in 1m59s
ea9aa4fd77
ltms closed this pull request 2026-09-03 11:53:39 +02:00
Owner

Merged to main as fa97f59.

I re-ran the mutation proof myself rather than taking the report on trust. Breaking the configured branch (if (false && ...)) turns MemberTrustModelReportTest red on exactly the dangerous case — a fleet with memberHerdrSocket set, silently reporting the same-uid text. Restored from a copy taken before the edit; git diff --exit-code on Fleetd.java is clean. Full build after the restore: 1264 tests, 0 failures.

Note on scope: IntelliJ has no fleetd project open in this session, so ide_diagnostics could not run. This merge is gated on mvn clean install alone.

Your caveat was right and I am acting on it — see fleet/fleetd#184. HerdrPeerLauncher.warnUnknownMemberEnvironment states the same claim this PR exists to remove, and now contradicts the startup line in the same log. Good catch, and correct not to widen the ticket yourself.

Merged to `main` as `fa97f59`. I re-ran the mutation proof myself rather than taking the report on trust. Breaking the configured branch (`if (false && ...)`) turns `MemberTrustModelReportTest` red on exactly the dangerous case — a fleet with `memberHerdrSocket` set, silently reporting the same-uid text. Restored from a copy taken before the edit; `git diff --exit-code` on `Fleetd.java` is clean. Full build after the restore: 1264 tests, 0 failures. Note on scope: IntelliJ has no `fleetd` project open in this session, so `ide_diagnostics` could not run. This merge is gated on `mvn clean install` alone. Your caveat was right and I am acting on it — see fleet/fleetd#184. `HerdrPeerLauncher.warnUnknownMemberEnvironment` states the same claim this PR exists to remove, and now contradicts the startup line in the same log. Good catch, and correct not to widen the ticket yourself.
Some checks are pending
CI / contract (pull_request) Successful in 53s
CI / build (pull_request) Successful in 1m59s

Pull request closed

Sign in to join this conversation.