deny_remote: default whitelist entries are active instead of commented out; pamusb-conf needs --whitelist-service / --unwhitelist-service

[mcdope]

Problem 1 — Whitelist entries are active by default

doc/pam_usb.conf (lines 99–108) ships with whitelist entries as live XML, not commented out:

<service id="gdm-password"><option name="deny_remote">false</option></service>
<service id="lightdm"><option name="deny_remote">false</option></service>
<!-- … etc … -->

The surrounding optional examples (e.g. the one_time_pad and quiet blocks at lines 76–87) are correctly wrapped in <!-- -->. The whitelist entries are not, so every new install silently activates them without the user making a conscious choice.

Expected behaviour: The whitelist block should be commented out and treated as an example/template only, consistent with all other optional entries in the default config.

The comment block already contains a template line that makes the intent clear — the active entries just need to be wrapped:

<!--
    Default whitelist for "deny_remote".
    Template: <service id=""><option name="deny_remote">false</option></service>

    <service id="gdm-password"><option name="deny_remote">false</option></service>
    ...
-->

Both doc/pam_usb.conf and debian/libpam-usb/etc/security/pam_usb.conf must be updated identically.

---

Problem 2 — No CLI tool to manage the whitelist

pamusb-conf has no way to add or remove a deny_remote service whitelist entry. Users must edit the raw XML manually, which is error-prone and inconsistent with the --add-user / --add-device / --reset-pads pattern.

Proposed new arguments

--whitelist-service <service-name>

• Looks up (or creates) the <services> block in the config
• If <service id="<name>"> already has deny_remote=false → inform user, no-op
• If <service id="<name>"> exists with other options → append <option name="deny_remote">false</option>
• If the element does not exist → create <service id="<name>"><option name="deny_remote">false</option></service>
• Follows the existing confirm-then-write flow (shouldSave() → writeConf())
• Respects --yes and --config flags

--unwhitelist-service <service-name>

• Finds <service id="<name>"> in the config
• Removes the <option name="deny_remote">false</option> child
• If no children remain after removal → remove the whole <service> element
• If the service or option is not found → inform user, no-op
• Same confirm-then-write flow

Example usage

pamusb-conf --whitelist-service gdm-password
pamusb-conf --whitelist-service lightdm --yes
pamusb-conf --unwhitelist-service xscreensaver

Implementation notes

Follow the addUser() pattern in pamusb-conf (lines 118–173):

• Parse with xml.dom.minidom
• Find <services> via getElementsByTagName('services')[0]
• Create/update <service> element and child <option>
• Reuse prettifyElement() + writeConf() helpers
• Add --whitelist-service= and --unwhitelist-service= to the getopt call (line 434)

Unit tests are mandatory per CONTRIBUTING.