OpPolicy problem/bug: Sending job as non-authorized user neverthelessprints job as root user

[Michael Sweet]

Kurt Pfeifle wrote:
> ...
> However, to make my initial testing faster and scriptable, I've turned
> to using the Unix commandline, running it as root, without requiring a
> real MS Windows client undergoing a clicking orgy to submit a job.

OK, so when you run as root you can authenticate as root using
certificates, regardless of whatever you pass in with '-U'.  This
is a feature, not a bug (yes, I am serious, and stop calling
me Shirley :)

The policy kicks the original print request back (unauthorized,
your -U isn't accepted), at which point the lp command tries to
authenticate.  Since you are running over localhost, the
authentication can use certificates.  Since you are running as
root, certificate 0 is readable and you get authenticated as root.

Now, if the limit was set via the requesting-user-name-allowed or
requesting-user-name-denied attributes (-u allow:... or -u deny:...
on the lpadmin command-line), your -U trick would work.  However,
policies with Require user or Require group rules but no AuthType
fall back on authentication when the supplied username doesn't
work.

You *could* also use the -h option with the hostname of the server
(so that localhost is not involved, so no root certificate), but then 
you'd have that "clicking orgy" since lp would be asking for a
password...

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