Debian Bug report logs - #614713
cups-pdf: installation asks for a password

Package: cups-pdf; Maintainer for cups-pdf is Debian CUPS Maintainers <pkg-cups-devel@lists.alioth.debian.org>; Source for cups-pdf is src:cups-pdf.

Reported by: Daniel Reichelt <debian@nachtgeist.net>

Date: Wed, 23 Feb 2011 00:27:01 UTC

Severity: important

Tags: help

Merged with 539156

Full log


Message #83 received at control@bugs.debian.org (full text, mbox):

Received: (at control) by bugs.debian.org; 9 Oct 2012 02:05:36 +0000
From debian@nachtgeist.net Tue Oct 09 02:05:36 2012
X-Spam-Checker-Version: SpamAssassin 3.3.1-bugs.debian.org_2005_01_02
	(2010-03-16) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.0 required=4.0 tests=BAYES_00 autolearn=ham
	version=3.3.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 10; hammy, 151; neutral, 191; spammy,
	0. spammytokens: hammytokens:0.000-+--(unknown), 0.000-+--(unknown),
	0.000-+--(unknown), 0.000-+--(unknown), 0.000-+--(unknown)
Return-path: <debian@nachtgeist.net>
Received: from srv04.itamservices.de ([88.198.54.146])
	by buxtehude.debian.org with esmtp (Exim 4.72)
	(envelope-from <debian@nachtgeist.net>)
	id 1TLPCR-0006Sy-Kb
	for control@bugs.debian.org; Tue, 09 Oct 2012 02:05:36 +0000
Received: from localhost (localhost [127.0.0.1])
	by srv04.itamservices.de (Postfix) with ESMTP id 5B13D40410
	for <control@bugs.debian.org>; Tue,  9 Oct 2012 04:05:33 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at srv04.itamservices.de
Received: from srv04.itamservices.de ([127.0.0.1])
	by localhost (srv04.itamservices.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id uZ4ecNnlkITa for <control@bugs.debian.org>;
	Tue,  9 Oct 2012 04:05:32 +0200 (CEST)
Received: from [10.0.0.101] (HSI-KBW-149-172-126-245.hsi13.kabel-badenwuerttemberg.de [149.172.126.245])
	by srv04.itamservices.de (Postfix) with ESMTPSA id 57217403E5
	for <control@bugs.debian.org>; Tue,  9 Oct 2012 04:05:32 +0200 (CEST)
Message-ID: <50738669.2000404@nachtgeist.net>
Date: Tue, 09 Oct 2012 04:05:29 +0200
From: Daniel Reichelt <debian@nachtgeist.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120922 Icedove/3.0.11
MIME-Version: 1.0
To: control@bugs.debian.org
Subject: Re-open: cups-pdf: installation asks for a password
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Delivered-To: control@bugs.debian.org
unarchive 614713
reopen 614713 !
severity serious
thanks
--


Hi Martin-Eric,

> 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.


Doing user-interaction during postinst other than by the use of debconf
is a violation of the Debian Policy, thus severity=serious.


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).

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.



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 13:56:02 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.