cupsd.conf: /admin/conf endpoint is missing authentication (unauthenticated config disclosure)

[HappyBasher]

Problem

In share/templates/cupsd.conf, the <Location /admin/conf> block has no AuthType/Require user restriction, unlike its sibling blocks <Location /admin> and <Location /admin/log> in the same file:

<Location /admin/conf>
  # Allow remote access to the configuration files...
  Order allow,deny
  Allow all
</Location>

CUPS's own upstream default cupsd.conf protects this location the same way as /admin and /admin/log:

<Location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  Order allow,deny
</Location>

Impact

Anyone who can reach port 631 can read the full raw cupsd.conf without any credentials. Verified live on a running linuxmuster server (CUPS 2.4.16-1ubuntu1.3, Ubuntu 26.04):

$ curl -s -o /dev/null -w '%{http_code}\n' http://localhost:631/admin/conf/cupsd.conf
200
$ curl -s -o /dev/null -w '%{http_code}\n' http://localhost:631/admin/log/error_log
401

The first request returns the complete server configuration; the second (correctly) requires authentication. Since <Location /> also allows unrestricted access (Allow all, intended for shared local-network printing), any host that can reach the CUPS port on the server can pull the configuration.

The /admin/conf endpoint also handles configuration uploads (used by the CUPS web admin UI to save edited config files), gated by the same <Location> block — so the same missing restriction likely also permits unauthenticated configuration writes, though this wasn't tested to avoid altering a live server.

Proposed fix

Align <Location /admin/conf> with the sibling blocks and upstream's own default, e.g.:

<Location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  # Allow remote access to the configuration files...
  Order allow,deny
  Allow all
</Location>

Found while reviewing cupsd.conf for CUPS-version compatibility in the context of #189.

[HappyBasher]

Confirmed the write path is open too, tested live on a test server (CUPS 2.4.16-1ubuntu1.3) with the owner's permission (snapshot available for rollback):

$ curl -T cupsd.conf http://localhost:631/admin/conf/cupsd.conf
HTTP 201

Sent completely unauthenticated, no session/cookie/credentials - and accepted. This matches CUPS's own scheduler code (scheduler/client.c), which handles config uploads as a plain PUT /admin/conf/cupsd.conf, gated only by cupsdIsAuthorized() against the <Location /admin/conf> block - which is exactly the block missing AuthType/Require user here.

The test payload was byte-identical to the live config (to avoid actually changing anything), and the file content was verified unchanged afterwards. However, even this no-op PUT made cupsd restart itself to apply the "new" config, and that restart raced with systemd's socket activation and failed once (Main process exited, code=exited, status=1/FAILURE) before systemd's automatic restart recovered it ~18s later. So beyond the confidentiality issue (unauthenticated read) and integrity issue (unauthenticated write), there's also a low-effort availability angle: an unauthenticated request against /admin/conf/cupsd.conf can knock the print scheduler over, even without changing its content.

No lasting impact on the test server - service recovered automatically, config content verified unchanged via checksum.