[Pkg-cups-devel] Re-open: cups-pdf: installation asks for a password
Martin-Éric Racine
martin-eric.racine at iki.fi
Mon Oct 20 12:15:36 UTC 2014
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
More information about the Pkg-cups-devel
mailing list