Participant Relationship Protocol

Back to matrix

D01-ND: No

Rationale

The identified Linux NFD Ethernet configuration retains elevated authority during routine operation. PrivilegeHelper records its original effective IDs; drop changes only effective IDs, while raise restores the privileged values. The newly traced PcapHelper::activate calls pcap_activate inside PrivilegeHelper::runElevated, which raises privileges for the operation and then drops them again. EthernetTransport uses this activation path, and EthernetFactory handles interfaces added after startup as well as face requests. Thus the mechanism is not merely a privileged installer followed by irreversible privilege removal. It fails D01 for this pinned configuration even when its current effective UID is an ordinary account. The documented Linux file-capability alternative also grants elevated networking authority (CAP_NET_RAW and CAP_NET_ADMIN).

Assessment method

Privilege lifecycle and live face-activation source trace; no runtime test

Source context

Pinned NFD 24.07 source and official FAQ, reviewed 2026-10-22

Outstanding qualification

This No is scoped to the identified NFD/Linux direct-Ethernet deployment, not all possible NDN implementations. It does not mean each packet needs a fresh elevation: established faces use their existing capture/injection handles. An application using a local Unix socket may itself be unprivileged, but D01 includes the local forwarder and any continuing helper. The macOS BPF-permission alternative and a hypothetical permanently reduced, pre-opened-face design are not qualified by this finding. No OS changes, capability grants, packet capture, runtime privilege test or complete-stack interoperability test was performed.

Public sources

Editorial evidence references

The following identifiers refer to research records not included in this public package; they are not public links.