Univention Bugzilla – Bug 41374
Printermoderation fails on restricted printers
Last modified: 2016-11-10 16:00:46 CET
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.
Ticket#2016052721000612
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
Created attachment 7942 [details] patch svn r71995 contains a typo when translating some string. The patch fixes this.
(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.
(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
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.
(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).
(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
(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.
(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?
* 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
Please create a corresponding YAML file for python-cups in ucs-school-4.1r2/docs/errata/staging/
(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
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
(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
(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?
(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).
(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
OK: error handling/displaying
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.