Bug 15057 - smbspool sets wrong auth-info-required value on failed authentication
Summary: smbspool sets wrong auth-info-required value on failed authentication
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Printing (show other bugs)
Version: 4.15.7
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: printing-maintainers
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-05-02 10:41 UTC by Elia Geretto
Modified: 2022-05-05 14:34 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elia Geretto 2022-05-02 10:41:11 UTC
The following command invocation triggers the buggy behavior:

```
$ AUTH_INFO_REQUIRED=none smbspool <printer-url> test test 1 1 /tmp/test.txt
ERROR: Session setup failed: NT_STATUS_ACCESS_DENIED
DEBUG: get_exit_code(nt_status=NT_STATUS_ACCESS_DENIED [c0000022])
ATTR: auth-info-required=none
DEBUG: Unable to connect to CIFS host: NT_STATUS_ACCESS_DENIED
$ echo $?
2
```

The program exits with `CUPS_BACKEND_AUTH_REQUIRED`, indicating that additional authentication information is required, but instead of printing:

```
ATTR: auth-info-required=username,password
```

as it should for the printer I am interacting with, it simply echoes back the value passed in through `AUTH_INFO_REQUIRED`, which is not necessarily correct.

This invocation is the same as the one CUPS performs when trying to print for the first time with a newly added authenticated printer. Even if the printer is authenticated, no `auth-info-required` attribute is required to be specified when adding the printer, the backend (smbspool) should specify which authentication information is necessary, if any.

Exiting with `CUPS_BACKEND_AUTH_REQUIRED`, while specifying `none` as `auth-info-required` value breaks the contract with CUPS and results in a job that is indefinitely held for authentication, while being marked as requiring no authentication information.

This bug breaks authenticated printing, unless the `auth-info-required` attribute is manually corrected after adding the printer. The workaround is:

```
lpadmin -p PRINTER -o auth-info-required=username,password  (for username + password)
lpadmin -p PRINTER -o auth-info-required=negotiate          (for Kerberos)
```

For additional context, see the discussion with Michael R Sweet here: https://github.com/OpenPrinting/cups/issues/373
Comment 1 Andreas Schneider 2022-05-05 06:48:21 UTC
This is not that easy.

What we could do is to check for AUTH_INFO_REQUIRED=none and NT_STATUS_ACCESS_DENIED and in this case return.

auth-info-required=samba

AUTH_INFO_REQUIRED=samba will first try to use kerberos and fallback to username/password. We don't know what the server supports.

The question is if cups can deal with that ...
Comment 2 Elia Geretto 2022-05-05 14:34:39 UTC
After commit [1], if `smbspool` reports that the job could not be authenticated, but it does not set the information required to authenticate it, CUPS will assume `username,password` as a fallback, so that it works at least in some cases. This, however, is a problem when the authentication should happen with Kerberos.

Regarding the solution of setting `auth-info-required` to `samba`, I am not sure that setting an arbitrary value is supported, because the documentation reports the expected values explicitly [2]. If `samba` is supported, though, that could indeed be a solution.

I am wondering if, when the anonymous authentication fails, a Kerberos authentication can be attempted to figure out if that authentication method is supported but fails, or is not supported at all. I am just guessing, but isn't this similar to what you are already doing when `auth-info-required` is set to `samba`?

[1]: https://github.com/OpenPrinting/cups/commit/f4e8437ddf6023645297c3c6a22105045084c0c9
[2]: https://www.cups.org/doc/spec-ipp.html