ti, 2012-10-09 kello 04:05 +0200, Daniel Reichelt kirjoitti: > unarchive 614713 > reopen 614713 ! > severity serious > thanks > -- > > > Hi Martin-Eric,
Seems that this re-opening went under my radar as it was sent directly to the BTS' control interface, which doesn't CC the maintainer or add the message body to the bug. > > just wanted to tell 2.5.1-3 works fine here and thanks for the quick > > action. > > I'm sorry, I wrote bull. > > My live-* build-system from back then somehow got messed-up and the > installation of cups-pdf worked, although it shouldn't have. This came > up again here [1]. > > > So I dug in again and sadly I have to revise the explanation about > encryption: the superfluous -E parameter to the lpadmin call in postinst > was just that: superfluous but not responsible for the password query > when run within a chroot. > > lpadmin has several ways of "gaining" authentication against a cups > daemon. The ones involved are > > > 1) "certificates" issued by the cups daemon (NOT to be confused with SSL > certificates, more to the point they should have been named s.th. like > "authentication tokens") [2], [3]. > Whenever a client tries to talk to cupsd on localhost, it tries to use > the certificate data read from /var/run/cups/certs/<PID> or ...certs/0 > (certs directory owned by lp:lpadmin, mode 511) and passes them to cupsd > for authentication. > > 2) interactive authentication, asking the user for a password if 1) > didn't succeed or the certs directory wasn't readable by the user invoking > lpadmin. > > > In case of installing cups-pdf within a chroot, said certs directory > just doesn't exist, so lpadmin has to resort to asking the user for a > password. Thanks for this in-depth analysis. As far as I can tell, this essentially makes CUPS itself non-installable inside a chroot. Makes one wonder what got into upstream CUPS authors to migrate to an architecture that requires a running daemon to work. > Doing user-interaction during postinst other than by the use of debconf > is a violation of the Debian Policy, thus severity=serious. It indeed is. > The simplest solution to this would be > > a) > - Check the availability of /var/run/cups/certs/0 > -- yes: run as before > -- no: skip invocation of lpadmin > > > Of course, that's not very elegant. Sadly, lpadmin has no way of > specifying a password on the command-line. If one wouldn't mind a > dependency on "expect", we could > > b) > - Check the availability of /var/run/cups/certs/0 > -- yes: run as before > -- no: via debconf ask the user for the root password (or user/pw tuple > of s.o. being a member of lpadmin group) > -- invoke lpadmin from an expect script, "interactively entering" the > password provided during the debconf stage > > > Personally, I'd vote for a). I would tend to agree. However, before I go ahead and implement this, I'd like to hear the opinion of CUPS maintainers about whether your analysis is correct and abotu what solutions they offer. > IF a correct run of lpadmin within the chroot was necessary, that case > could be handled by copying .../certs/0 into the chroot prior to the > installation of cups-pdf and removing it afterwards. However, most of > the times I expect cups-pdf to already have been installed outside the > chroot, so the printer queue should already exist and an invocation of > lpadmin within the chroot would be superfluous anyway. > > > Opinions? > > Daniel > > > > [1] http://lists.debian.org/debian-live/2012/08/msg00078.html > [2] http://www.cups.org/documentation.php/doc-1.4/security.html Section > "Authentication Issues", #3 > [3] cups source package, cups/auth.c, line 655 (in v1.4.4) ff. > > Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-dist
