CUPS interaction (authentication with LIBCUPS)

[Michael R Sweet]

Andrew Bartlett wrote:
> On Sun, 2005-06-05 at 18:22 +0200, Dr. Uwe Meyer-Gruhl wrote:
> 
>>Hi,
>>
>>
>>there is a problem with SAMBA interacting with CUPS: Alas, in CUPS, 
>>there is no way to discriminate with regard to authentication between 
>>different input feeds (e.g. IPP vs. commandline vs. LIBCUPS). So, if 
>>somebody secures his IPP server, he cannot print via SAMBA any more, 
>>since there is no way that SAMBA can be configured to send the 
>>authentication.
>>
>>Although one can argue that this is CUPS's fault, this could be solved 
>>in SAMBA if a "cups user" and "cups password" were introduced into 
>>smb.conf and used in the LIBCUPS callback (source/printing/print_cups.c):
> 
> 
> I thought that cups had some 'as root' hack, where a 128 bit secret was
> passed across, to prove that we are the root on the same host?  

It does, but it solves a different problem.

> What we really want however is to ensure we act as the user, not as the
> system, but without their password, and preferably also on remote hosts.
> We don't get this stuff right at the moment (I'll file another bug) but
> a cups user/cups password would make it worse, I think.
> 
> I think what we need is a brainstorm with the CUPS folks, who are known
> to hang out in these parts :-)

:)

OK, there are two known authentication issues with SAMBA and CUPS:

     1. For incoming jobs, SAMBA runs as the user and passes the job
        through.  If the printer or operation requires authentication,
        then the job will fail unless the user is part of the system
        group defined in cupsd.conf (that's where the local 128-bit
        certificate business comes in...)

     2. For outgoing jobs, the smbspool program is run as root, but
        potentially provided a username and password in the device URI.
        However, if no username or password is provided in the URI,
        then we have no way of passing the authentication information
        to the Windows server.

#1 should be fairly well solved in CUPS 1.2, where we officially
start supporting and using domain sockets for local access and
can get the UID of the requester from the OS.  This is already
available in trunk and in MacOS X 10.4, BTW...

#2 is a much harder problem, mainly because we don't know whether
the user needs a Kerberos ticket or a username/password.  A similar
issue exists for IPP printing, BTW, and at this point the solutions
on Linux revolve around a GNOME hack which runs a user session
cupsd process which can ask the logged-in user for a password.
(this is a hack because is doesn't work for all cases and adds a
largish overhead and complexity to a user session...)

We're looking at various notification and caching designs for
this problem (notify the user when a job has to be authenticated,
user provides credentials + how long they want to store them -
this job, 1 hour, forever, etc.), and then the backend gets the
credentials added to the device URI.  Clearly there are a LOT of
issues with any caching of credentials, and we will be proceeding
carefully and slowly with this issue AFTER CUPS 1.2 has been
released...

FWIW, IPP doesn't really address the issue of authentication, but
a) says to use HTTP and TLS methods, and b) does a lot of hand
waving... :)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com