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

[Kurt Pfeifle]

Michael Sweet wrote:
> 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

I suspected that when I asked if it "works as designed"...

> (yes, I am serious, and stop calling
> me Shirley :)

OK, for now...

;-)

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

What would break if I disabled authentication via local certificates
for the testing?

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

Yes, but that is specifically not wanted by the customer, because the
"management overhead" to maintain those lists for 100s of printers
and 1000 of users is not very sexy...

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

Yes, I had that idea too...

> but then
> you'd have that "clicking orgy" since lp would be asking for a
> password...

Since the test user accounts will not have a very complicated, se-
cure password, this is still a good + fast alternative for the 1st
series of tests (and some automated scripting of the tests).

Thanks for the detailed reply.

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany