Bug 41374 - Printermoderation fails on restricted printers
Printermoderation fails on restricted printers
Status: CLOSED FIXED
Product: UCS@school
Classification: Unclassified
Component: UMC - Printermoderation
UCS@school 4.1
Other Linux
: P5 normal (vote)
: UCS@school 4.1 R2 vXXX
Assigned To: Felix Botner
Florian Best
: interim-3
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-05-27 17:39 CEST by Sönke Schwardt-Krummrich
Modified: 2016-11-10 16:00 CET (History)
3 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.137
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2016052721000612
Bug group (optional): External feedback
Max CVSS v3 score:


Attachments
patch (2.58 KB, patch)
2016-08-29 19:28 CEST, Florian Best
Details | Diff
patch2 (1.60 KB, patch)
2016-09-29 15:08 CEST, Florian Best
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sönke Schwardt-Krummrich univentionstaff 2016-05-27 17:39:38 CEST
If a restricted printer is used as target printer for printer moderation, the print will fail due to access restrictions.

By default, the following command is used by the UMC printer moderation module if the teacher (e.g. "d.krause1") tries to print a print job of student user "anton4".

root@slave51:~# lpr -P Laserprint -U anton4 -J release-notes-3.2-3-de.pdf.ps release-notes-3.2-3-de.pdf.ps -H slave51.nstx.local  ; echo $?
0

If the access to the printer "Laserprint" is restricted to e.g. only teachers, lpr asks for credentials regardless of the given user. This way, the print job will fail.

root@slave51:~# lpr -P Laserprint -U anton4 -J release-notes-3.2-3-de.pdf.ps release-notes-3.2-3-de.pdf.ps -H slave51.nstx.local  ; echo $?
Das Kennwort für „anton4“ auf „slave51.nstx.local“? lpr: Nicht berechtigt
1


A workaround would be the removal of "-H $PRINTSERVER" for argument list. But this workaround will fail, if the print spool service is not located on the school server/UMC server.
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2016-05-30 10:32:02 CEST
Ticket#2016052721000612
Comment 2 Felix Botner univentionstaff 2016-08-22 13:53:04 CEST
If a printer is restricted (only a group is allowed to use the printer), other users can't use this printer, regardless of authentication

-> more /etc/cups/printers.conf| grep Allow
AllowUser @lehrer-school1

-> lp -d printer1 -h 10.200.7.150 -U s1 /etc/mtab 
Das Kennwort für „s1“ auf „10.200.7.150“? 
lp: Drucken nicht erlaubt.

Authentication is configured in /etc/cups/cupsd.conf:

<Location /printers/printer1>
    Order Allow,Deny
    Allow From localhost
    Allow From master.w2k12.test
    AuthType Basic
    Require valid-user
    Satisfy any
</Location>

=> Connection from localhost are allowed (also from master.w2k12.test, but this does not work as cups expects an ip address here) and connections after basic authentication

Next comes the authorization -> "AllowUser @lehrer-school1". If s1 is not member of "lehrer-school1", he can't use the printer.


(1) Authorization
use the name of the UMC user for the print command (the teacher), not the name of the student (

(2) Authentication
We need a password for the authentication, except for localhost (printing from localhost is allowed with "Allow From localhost" statement)

=> we could add all school slaves to "Allow From " to avoid the need for a password
=> or we could print as machine account, but than all machines need to be in the list of allowed users for the printer
Comment 3 Florian Best univentionstaff 2016-08-29 19:28:41 CEST
Created attachment 7942 [details]
patch

svn r71995 contains a typo when translating some string. The patch fixes this.
Comment 4 Florian Best univentionstaff 2016-08-29 19:29:21 CEST
(In reply to Florian Best from comment #3)
> Created attachment 7942 [details]
> patch
> 
> svn r71995 contains a typo when translating some string. The patch fixes
> this.
It contained also space/tab mixes.
Comment 5 Felix Botner univentionstaff 2016-08-30 10:52:23 CEST
(In reply to Florian Best from comment #4)
> (In reply to Florian Best from comment #3)
> > Created attachment 7942 [details]
> > patch
> > 
> > svn r71995 contains a typo when translating some string. The patch fixes
> > this.
> It contained also space/tab mixes.

ok, thanks

ucs-school-umc-printermoderation
 * in case the print server is the server, on which the module is running,
   lpr is called without -H server
   -> that way we don't need to authenticate to print on restricted printers
   (see "Allow From localhost" for restricted printers in /etc/cups/cupsd.conf)
 * as username -U for the lpr call, we have to use the name of the UMC user 
   (not the username of moderated job), otherwise authorization does not work
 * in case the lpr call returns != 0, a error message is displayed with the
   stderr of the lpr call

=> printing on restricted printers works, but only for printers, which are provided by the server on which the printermoderation module is running

=> if one uses a restricted printer on a different server, at least a proper
error message is displayed, something like this:
Auf Drucker printer konnte nicht gedruckt werden:  Drucken nicht erlaubt

YAML: ucs-school-umc-printermoderation.yaml
Scope: ucs-school-4.1r2
Comment 6 Florian Best univentionstaff 2016-09-23 16:07:18 CEST
OK: printing is done as the teacher and works if printing is disallowed for the teacher
OK: YAML
OK: error message if printing is disallowed even for the teacher:
"Failed to print on PDFDrucker: lpr: Drucken nicht erlaubt."
OK: printing on a different host works if the printer is not restricted
FAIL: No password is transmitted when the remote printer has access restriction. This causes always the error (even if the teacher is allowed to print):
"""
Failed to print on MasterPrinter: Das Kennwort für „i.heine“ auf „xen7.school.local“? lpr: Nicht berechtigt
"""

I am unsure about leaving out "-H server" because I think there was a bug entry to remove the "Allow from localhost" rule but I can't find the bug anymore.
Comment 7 Sönke Schwardt-Krummrich univentionstaff 2016-09-26 11:48:25 CEST
(In reply to Florian Best from comment #6)
> FAIL: No password is transmitted when the remote printer has access
> restriction. This causes always the error (even if the teacher is allowed to
> print):
> """

Do we always have the cleartext password? AFAIR the cleartext password is not always available in UMC (modules).
Comment 8 Florian Best univentionstaff 2016-09-26 12:00:29 CEST
(In reply to Sönke Schwardt-Krummrich from comment #7)
> (In reply to Florian Best from comment #6)
> > FAIL: No password is transmitted when the remote printer has access
> > restriction. This causes always the error (even if the teacher is allowed to
> > print):
> > """
> 
> Do we always have the cleartext password? AFAIR the cleartext password is
> not always available in UMC (modules).

When logged in via SAML we don't have the password.
We have a decorator which forces with a simple dialog to regular login.

from univention.management.console.modules.decorators import require_password
@require_password
Comment 9 Sönke Schwardt-Krummrich univentionstaff 2016-09-26 12:10:07 CEST
(In reply to Florian Best from comment #8)
> When logged in via SAML we don't have the password.
> We have a decorator which forces with a simple dialog to regular login.
> 
> from univention.management.console.modules.decorators import require_password
> @require_password

Great. I was unaware of that.
@Felix: 
1) please adjust the UMC module accordingly so the password is asked before the user tries to print
2) additionally please pass the user password always to lpr, so we are safe if the "allow from localhost" ACL is removed in future.
Comment 10 Florian Best univentionstaff 2016-09-26 12:12:30 CEST
(In reply to Sönke Schwardt-Krummrich from comment #9)
> 2) additionally please pass the user password always to lpr, so we are safe
> if the "allow from localhost" ACL is removed in future.

Is it possible to not pass the password via CLI argument - so that it doesn'T occur in the process list?
Comment 11 Felix Botner univentionstaff 2016-09-26 17:51:41 CEST
* added @require_password decorator (so we have always self.password)
* replaced lpr with python-cups, always authenticate the cups connection

ucs-school-umc-printermoderation.yaml


!!! Attention !!!

Added python-cups as dependency to ucs-school-umc-printermoderation.
Don't forget to copy the python-cups packages to the new ucs@school app

!!!!!!!!!!!!!!!!!

added Bug #42509 to move python-cups to maintained
Comment 12 Sönke Schwardt-Krummrich univentionstaff 2016-09-27 09:34:31 CEST
Please create a corresponding YAML file for python-cups in 
ucs-school-4.1r2/docs/errata/staging/
Comment 13 Felix Botner univentionstaff 2016-09-27 09:48:27 CEST
(In reply to Sönke Schwardt-Krummrich from comment #12)
> Please create a corresponding YAML file for python-cups in 
> ucs-school-4.1r2/docs/errata/staging/

done
Comment 14 Florian Best univentionstaff 2016-09-29 15:08:29 CEST
Created attachment 8053 [details]
patch2

OK: printing still works
OK: printing on remote server work now
OK: SAML
OK: error handling
REOPEN: error messages aren't user friendly. Please see the attached patch which fixes this.
OK: YAML
Comment 15 Felix Botner univentionstaff 2016-09-30 15:16:09 CEST
(In reply to Florian Best from comment #14)
> Created attachment 8053 [details]
> patch2
> 
> OK: printing still works
> OK: printing on remote server work now
> OK: SAML
> OK: error handling
> REOPEN: error messages aren't user friendly. Please see the attached patch
> which fixes this.

fixed the indentation problem

not the rest,
from my point of view it is always better not to mess around with error message. What is the point? Normal users don't understand the problem (regardless of the fact that we try to "pretty up" the error message). But the error code and the unaltered error message helps admins/supporters to find the problem and a solution, and that should be the focus
 
but that's just my opinion
feel free to reopen
Comment 16 Florian Best univentionstaff 2016-10-04 17:28:12 CEST
(In reply to Felix Botner from comment #15)
> from my point of view it is always better not to mess around with error
> message. What is the point? Normal users don't understand the problem
> (regardless of the fact that we try to "pretty up" the error message). But
> the error code and the unaltered error message helps admins/supporters to
> find the problem and a solution, and that should be the focus
A user should never see a python structure in a error message like it is currently the case:
"""Failed to print on PDFDrucker: (1030, 'client-error-not-found')"""

After the patch the error message look like:
"""Failed to print on PDFDrucker: No permission to print (error 1027)."""
"""Failed to print on PDFDrucker: Wrong password (error 4096)."""
"""Failed to print on PDFDrucker: client-error-not-found (error 1030)."""

The patch still contains the errno and the description/strerr which helps in debugging. For two common cases I mapped a more human readable description to remove the '-' from strerr. I think the errno is enough to debug the error as admin. But feel free to always include the error string, e.g.:

"""Failed to print on PDFDrucker: Wrong password (error 4096 cups-authorization-canceled)."""

@Sönke: Your opinion?
Comment 17 Sönke Schwardt-Krummrich univentionstaff 2016-10-10 09:10:15 CEST
(In reply to Florian Best from comment #16)
> > from my point of view it is always better not to mess around with error
> > message. What is the point? Normal users don't understand the problem
> > (regardless of the fact that we try to "pretty up" the error message). 

I don't think so. If the error message looks like spaghetti code, normal users just click it away. If the error message is a little bit more readable like Florian's suggestion

> """Failed to print on PDFDrucker: No permission to print (error 1027)."""
> """Failed to print on PDFDrucker: Wrong password (error 4096)."""
> """Failed to print on PDFDrucker: client-error-not-found (error 1030)."""

users will likely remember the error message and report it to the helpdesk/to Univention. 
 
> @Sönke: Your opinion?

The patch2 only handles 2 known error messages, all other error messages are shown unaltered and the error message is shown as plain text and not as tuple.

@Felix: please apply patch2 (or something similar).
Comment 18 Felix Botner univentionstaff 2016-10-10 12:53:51 CEST
(In reply to Sönke Schwardt-Krummrich from comment #17) 
> @Felix: please apply patch2 (or something similar).

ok, done



scope: ucs_4.1-0-ucs-school-4.1r2
src: ucs-school-umc-printermoderation
fix: 13.0.3-7.67.201610101249
Comment 19 Florian Best univentionstaff 2016-10-11 10:33:43 CEST
OK: error handling/displaying
Comment 20 Sönke Schwardt-Krummrich univentionstaff 2016-11-10 16:00:46 CET
UCS@school 4.1 R2 v7 has been released.

http://docs.software-univention.de/changelog-ucsschool-4.1R2v7-de.html

If this error occurs again, please clone this bug.