5.2 The Access Check

2 min read

The control object and its check are PSPU §6.4's. resolvd makes the check after the request has been decoded and before anything else is done with it.

5.2.1 The check #

1. The connecting peer's token is opened from the socket. When it cannot be, resolvd logs control: no peer token: <error> and the request is denied.
2. A KACS access check is made of the request's right against the control object's descriptor, with that token. A check that cannot be completed counts as a denial.
3. A denied request is answered access denied (§5.1).

5.2.1.1 The generic mapping #

The check uses this generic mapping:

5.2.1.2 Decoding comes before the check #

A request is decoded before it is checked, so a malformed request gets its decoding error whoever sent it, and an unknown query gets unknown query rather than access denied.

5.2.1.3 The answer does not depend on the caller #

The peer's identity is used for this check and for nothing else. Every caller allowed to ask gets the same answer to the same question.

5.2.2 The compiled default descriptor #

The descriptor is ControlSecurity when it holds a valid self-relative descriptor, else the compiled default (§2.3):

5.2.3 A new descriptor applies to later requests #

The descriptor is rebuilt whenever the registry configuration changes (§2.3). A request decoded after the change is checked against the new one; a request already being answered is not checked again.

5.2.4 What the control object does not govern #

The stub listener is not checked against the control object (PSPU §6.8): anything on the machine that can reach 127.0.0.53 can ask. A program denied RESOLVER_QUERY on the native socket still resolves names through the stub listener. The NSS shim uses the native socket, so for such a program getaddrinfo fails (§7.1) while a resolver that speaks DNS directly succeeds.

Edit this page