v0.5.11 — A window that can reach the daemon it was built for

Found by being asked how about the gui, and realising the window had only ever been asked its version.

The window could not work the way the README says to run it

under the service:   srw------- root root         → PermissionError [Errno 13]
started with sudo:   srw------- blessdyb blessdyb → {"ok":{"version":"0.5.9","enforcing":true,…}}

The socket is mode 0600 and belongs to SUDO_UID when there is one. Under a systemd unit there is no SUDO_UID, so it belongs to root — and the window, which runs as a person, is refused by the kernel. systemctl enable --now flowlightd is what the README tells people to do, and it was the one configuration in which the window could not work at all.

--socket-owner

# in the unit, which now carries this commented with the reason beside it:
ExecStart=/usr/sbin/flowlightd --socket-owner your-name

• Resolved by reading /etc/passwd, not through getpwnam, for the reason the address lookup speaks DNS itself: this binary is statically linked against musl, which reads that file and does not consult NSS. Parsing it here means the answer does not depend on what it was linked against — and it can be tested against a file written out rather than against whoever happens to exist on the machine running the tests.
• A name nobody has is refused. A socket belonging to a uid nobody has is a socket nothing can open.
• A bare number is taken at its word, because a container with no password file is a normal place for this to run.
• Fatal rather than warned about, because it is an explicit instruction, and the alternative is a machine that watches everything and offers no way to look at it.

Both guards now run before the kernel is touched

The database lock from v0.5.9 sat beside Store::open, which is late. The evidence was in its own output:

not intercepting: listening on 127.0.0.1:7891 …: Address in use (os error 98). Watching continues.
Error: another flowlightd (pid 19788) is already watching with …

A daemon about to refuse to run had already loaded its programs, attached its probes and tried to bind the proxy port. The lock and the socket owner are resolved immediately after the arguments now, before tracefs is read and before anything is loaded.

Verified

Six unit tests over the password-file parse and owner_from — by name, by number, comments and malformed lines stepped over, a missing file, an explicit name winning, and a name nobody has refused. The smoke test asserts that a socket asked to belong to root belongs to root, and that a name nobody has is refused.

Two of my own mistakes on the way, both caught rather than shipped: the flag's declaration never landed because the script that wrote it exited early, and the first version of the smoke check started a second daemon against the database the one under test was already watching — where v0.5.9's lock refused it, which was the feature working and the test being wrong.