Kerberised printing to a Windows print queue

[Michael Sweet]

Tom Shaw wrote:
> Hi Michael
> 
> I'm was just going through the steps of adding a use_kerberos option
> to smbspool, and I have a couple of questions about how to do this the
> Right Way. (If you're not the right person to answer this could you
> direct me to the person who is?)
> 
> 1) Is it appropriate to use the "options" argument? I'm guessing not
> because only the ipp backend seems to use that, while the other
> backends append options to the URI.

The options argument contains print job options, so you want to
use the device URI to store any options that are global to a job.

> 2) I've noticed that the options list appended to eg the serial URI is
> slightly non-standard.
> 
> searching via google:
> http://www.google.com/search?hl=en&lr=&ie=UTF-8&q=cups+backend&btnG=Search
> 
> cups URI:
> serial:/dev/ttyS2?baud=1200+bits=8+parity=none+flow=none
> 
> Note that HTTP GET uses '+' as a replacement for "space", and '&' as
> an option separator, while CUPS uses '+' as the option separator.

Oops, you are right.  We will update this (and support both + and
&) in a future CUPS release (this is now STR #842)

> Do you think it would be better for me to follow the CUPS way or the
> standard way?

I would support both + and & to avoid confusion in the CUPS
world.

> 3) How trustworthy is the "user" argument that is passed to the
> backend? I don't want to allow an impersonation attack where for
> example a user can use up another user's print quota.

If authentication is enabled, it is as trustworthy as the
authentication you are using.  The default configuration does
not authenticate the username, so keep that in mind.

> Anyway.. In terms of making CUPS itself kerberised, I've been thinking
> through what my intended patch will achieve. My goal is to allow a
> user to print via a local CUPS server using the kerberos credentials
> that are stored on that local machine. The way I plan to do this is to
> have smbspool seteuid() to the user and use the existing smb
> infrastructure to authenticate to the print server.
> 
> I believe this method has no chance of working if the CUPS server is
> remote (ie on a different machine to the user), because smbspool on
> that machine will not have access to the user's credentials cache.
> That situation is beyond my experience so I'm not sure how it could be
> solved.

There appears to be a "standard" method (standard meaning it is how
MS does it) of passing Kerberos credentials over HTTP.  If we can
implement this in CUPS, then I think the remote Kerberos printing
problem will be solved and you will also be able to retrieve and
pass on the credentials when printing via SMB or IPP to the next
server.

The only problem I see with using seteuid() is that it requires a
local account on the CUPS server.  While this is probably the most
usual case in a homogeneous environment, we also have a lot of users
that setup print servers for users that don't have a local account.

In any case, your patch seems like a good first step towards full
Kerberos support.  Thanks!

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com