Here is more detailed explanation and call to action. Root cause and upstream fix
Following up with the mechanism, since the local-vs-AD comparison above needs explaining. scheduler/auth.c strips any @domain from the username before authorization checks: ``` /* Strip any @domain or @KDC from the username and owner... */ if ((ptr = strchr(username, '@')) != NULL) *ptr = '\0'; ``` So [email protected] is truncated to testuser, and CUPS then checks that name. There is no local account called testuser, so @OWNER never matches and the request is refused. This also explains why my local test account succeeded: [email protected] was truncated to localtestuser, and a real local account with that name existed (I had created it in an earlier test). The check passed by coincidence, not because the name shape is acceptable. So the @ and . characters are irrelevant — what matters is whether the stripped short name resolves to a local user. Security implication. The upstream reporter flags the same behaviour as a privilege-escalation risk: a local user whose name matches the local part of a domain user's name is treated as that domain user for authorization purposes. My test above is an accidental demonstration — an unrelated local localtestuser account was enough to authorise operations for a name that was not it. The fix already exists upstream. OpenPrinting/cups PR #1029 (merged 2024-08-13, fixes issue #1001) makes the stripping optional via a new StripUserDomain directive in cups-files.conf, defaulting to off. It was backported to the 2.4.x branch for release 2.4.11 by the 2.4.x release manager (zdohnal). issue: https://github.com/OpenPrinting/cups/issues/1001 PR: https://github.com/OpenPrinting/cups/pull/1029 Confirmed the patch is not present in 2.4.7-1.2ubuntu7.14: ``` $ echo 'StripUserDomain No' | sudo tee -a /etc/cups/cups-files.conf $ sudo cupsd -t Unknown directive StripUserDomain on line 1 of /etc/cups/cups-files.conf. ``` SRU considerations Impact: on AD-joined machines using sssd with fully-qualified usernames, no domain user can print or cancel their own jobs. lp returns Unauthorized; GUI applications fail with a generic "Could not start printer" error. This affects every AD-joined Ubuntu desktop, which is a common enterprise deployment. Fix: cherry-pick commit f09c079 (PR #1029). It is small and self- contained, and is already in upstream 2.4.11. Test case: on an AD-joined 24.04 machine with sssd and fully-qualified usernames, log in as a domain user and run lp -d <queue> /etc/hostname. Before: lp: Unauthorized. After: the job is queued. Regression potential: this changes behaviour for anyone who relied on [email protected] being treated as local user — upstream's 2.4.x maintainer noted this when accepting the backport. The new directive defaults to off (no stripping), so the previous behaviour remains available via StripUserDomain Yes. The old behaviour is itself the security issue described above, so defaulting away from it seems right. Workaround in the meantime: comment out Require user @OWNER @SYSTEM in the job-operations <Limit> block of /etc/cups/cupsd.conf (and in <Limit Cancel-Job> if users need to cancel their own jobs), then restart CUPS. This weakens the policy — any local user can then act on another's jobs — so it is not a good permanent answer. ** Bug watch added: github.com/OpenPrinting/cups/issues #1001 https://github.com/OpenPrinting/cups/issues/1001 ** Tags added: sru -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2165919 Title: AD/sssd users cannot print: CUPS strips @domain before @OWNER check (upstream #1001) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/2165919/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
