Bug 230613

I was able to reproduce the same behavior on a straight rhel5/targeted
system with the default cupsd.conf, which has this:

  # Only the owner or an administrator can cancel or authenticate a job...
  <Limit Cancel-Job CUPS-Authenticate-Job>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>

According to the comment, it seems that the behavior we're seeing
isn't right.  Is the cupsd.conf file wrong or is the code not doing
the right thing?

This is how CUPS is intended to work, yes.  The 'Require user' with no AuthType
is basically a protection against accidentally cancelling someone else's job.

The cancel request is sent over IPP, with a 'requesting-user' attribute.  How
that attribute is validated depends on the AuthType.

So is the comment in the cupsd.conf file wrong then?  It says that only the
owner or an administrator can cancel a job but that is not the case.

It seems like this feature will surprise people.  In RHEL4 you cannot cancel
someone else job but in RHEL5 you can by default?  Seems like the default
settings should be the same and if someone wants to relax their system
then they can choose to do that.

Well, the comment might be strictly correct depending on what the AuthType is.

The server behaviour isn't any different from RHEL-4: if someone made their own
'cancel' binary by making a CUPS API application, or took the RHEL-5 one, and
ran it against a RHEL-4 scheduler the same would apply.

I've filed a bug upstream about the default configuration, to gather feedback
about changing it.

Upstream response to "Perhaps there should be an 'AuthType Basic' for job
cancellation in the default configuration?":

"No, because then you can't do "cancel 123" from the command-line without
providing a password, which will be a) annoying and b) break existing installs."

I tend to agree -- if it is really a requirement that users authenticate
themselves before they are allowed to cancel a job, that change is best made at
the site level.

That said, perhaps a better authentication scheme, not requiring passwords when
authenticating as the current user, could be created.

or at least fix the comment in the cupds.conf file so it describes the
behavior correctly.

I still think its bogus that in RHEL4 a user can't cancel another user's
job with the default setting and with RHEL5, a user can.  I think the
inconsistent behavior will bother people, once they realize its there.
Is there really no authentication scheme that works like it used to?

If we're going to leave the behavior as it is, then I think we need to
at least fix the comment.

I'd like to re-iterate what I said in comment #4: the server behaviour in RHEL-5
is no different in this respect than it was in RHEL-4.  There is no user
authentication for cancelling jobs in the default configuration.  The difference
is that the 'cancel' command now provides a '-U' option for asserting a
different username than the current one.

Changing the comment is a good idea.  Unfortunately it is more than just
changing the default cupsd.conf file we ship since occasionally that file will
be generated by cupsd itself.  I have submitted STR #2274 with some suggested
wording, to try to keep in step with the upstream source.

I saw what you said in comment #4 and don't want to beat a dead horse but 
from a user's perspective, the behavior is very different.  In RHEL-4 I'm
not able to cancel someone else's job.  I get an error telling me its not
my job.  I don't know where the enforcement happens but that's the behavior
I see.  With RHEL5 and the introduction of the -U flag on lprm, I'm able
to cancel another user's job.  If I'm going to assert a different user,
shouldn't I at least have to athenticate?  

You still get that same error on RHEL-5 except if you use the -U flag.

> In RHEL-4 I'm not able to cancel someone else's job.

Well, unless you use a 'cancel' binary that provides a -U option, or write
yourself a little program to submit an IPP request with a different
requesting-user-name attribute.  Or (for that matter) unless you run 'cancel'
under gdb..

> If I'm going to assert a different user, shouldn't I at
> least have to athenticate?

The point is that the *server* needs to authenticate if it is to be an
authenticated action.  All '-U' does at the client end is put a different user
name in the IPP request.  The server just compares the requesting-user-name
attribute with the owner of the job (i.e. the requesting-user-name attribute
that was given in the create-job IPP request).

If 'AuthType Basic' is set, *all* users have to authenticate, regardless of
whether -U was used for the client program submitting the request.  So it isn't
a case of 'assert different user -> have to authenticate' -- user authentication
is either on or off (for each particular action; here we're talking about
cancel-job).

It sounds like you're asking for a return to the RHEL-4 state of affairs, which
is equivalent to patching out the '-U' option in the cancel/lprm program and
leaving the default configuration alone.  Is that right?

> If 'AuthType Basic' is set, *all* users have to authenticate, regardless 
> of whether -U was used for the client program submitting the request.  
> So it isn't a case of 'assert different user -> have to authenticate' -- 
> user authentication is either on or off (for each particular action; 
> here we're talking about cancel-job).

What I see on my RHEL5 installation is that a normal user I can cancel
my own job without authenticating.  If I try to cancel someone else's
job I'm asked to authenticate but it my passwd isn't accepted.  If I
try to cancel someone else's job and use the -U, it works. 

[ljk@kipper ~]$ lpq
hoare is not ready
Rank    Owner   Job     File(s)                         Total Size
1st     root    7       passwd                          2048 bytes
2nd     ljk     8       group                           1024 bytes
[ljk@kipper ~]$ lprm 8
[ljk@kipper ~]$ lprm 7
Password for ljk on localhost?
Password for ljk on localhost?
Password for ljk on localhost?
Password for ljk on localhost?
lprm: Unauthorized
[ljk@kipper ~]$ lprm -U root 7

The behavior I'm seeing doesn't seem to match your description of
how it should work.  What passwd was it looking for when it prompted
me?  (My passwd and the root passwd are the same on this system.)

If you're saying that in RHEL4, cupsd always supported this behavior
but RHEL4 shipped no commands to take advantage of it then I buy that.
However, now you're shipping commands that take advantage if it, it
seems like you're introduced a security problem.

I also don't understand why lpadmin behaves differently from cancel.
In the lpadmin case, I can use -U but it wants root's paswd:

[ljk@kipper ~]$ /usr/sbin/lpadmin -U root -p ljkprinter -D "created as ljk"
Password for root on localhost?
[ljk@kipper ~]$

That's how I'd expect lprm to work with -U.  I get that behavior once
I added AuthType Basic here:
  # Only the owner or an administrator can cancel or authenticate a job...
  <Limit Cancel-Job CUPS-Authenticate-Job>
    AuthType Basic
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>

I guess the bottom line is that if the -U option is going to be there,
then by default it ought torequire authentication.  If that means
also authenticating users managing their own jobs, its annoying but
preferable to the way it is now.   

I think the problem with the "-U" flag is greater than just canceling
jobs.  I'm able to queue a job as another user too.

[ljk@kipper ~]$ lpr -U root /etc/passwd
[ljk@kipper ~]$ lpq
hoare is not ready
Rank    Owner   Job     File(s)                         Total Size
1st     root    12      passwd                          2048 bytes
[ljk@kipper ~]$

That seems way too permissive for a default configuration.

I would agree with Linda. I think that users should not be able to cancel each
other's jobs without explicitly allowing it in the config. The admin should be
able to cancel anything. I think this is reasonable behavior.

Regarding queueing jobs as another user, that is something that has to be fixed.

What you are asking is that every time anyone (a) prints, or (b) cancels a job,
they are asked for their password.

Right-clicking on a printing job in the job manager and selecting Cancel:
password prompt (note: this isn't even implemented as far as I am aware).

File->Print from any application: password prompt. (Is this implemented by any
applications?)

I really don't see this being acceptable to the majority of users.

See STR #2277 for a first attempt at a patch to implement UNIX domain socket
authentication.

Klaus, can you provide feedback on this bug?

CAPP/LSPP don't have specific requirements for the handling of the printer
queue. There is the general requirement that if audit records are generated for
user actions the loginuid must match the actual submitting user and not an
impersonated user. If authentication is involved, the usual rules apply,
including audit of all authentication, use of pam_tally2 or equivalent to lock
out users after too many invalid password guesses, and respecting password
expiry and other standard PAM auth features.

I agree with Linda and Steve that allowing users to delete and submit jobs as a
different user (with no authentication) is very unexpected, and I agree also
with Tim that it's unacceptable to prompt for the password even in the default
case of submitting or cancelling jobs as yourself. I only briefly looked at the
proposed approach on the mailing list, but using the credentials provided by the
kernel sounds like a good approach.

I tested this patch in combination with the latest cups-lspp.patch and everthing
works correctly.

When attempting to remove another user's job via the -U option I am prompted for
that user's password.  When removing my own jobs with or without the -U option I
am not prompted.

This looks good. tested with 1.2.4-11.6.el5 and seems fixed.

But isn't upstream yet, is it?

You may close the bug

1.2.4-11.6.el5 does not contain the fix.

No, the patch is not upstream yet, and I have not yet had feedback about it.

(In reply to comment #19)
> 1.2.4-11.6.el5 does not contain the fix.
> 
> No, the patch is not upstream yet, and I have not yet had feedback about it.

I was trying to remove a root-owned job using a regular user (like I did in the
first testcase in #0) and was asked about the root's password every time, so I
thought it was fixed.

But the behavior indeed changed.

Seems like because of the patch to #229673, now MAC checks are being applied to
this operation, so when in enforcing mode, even when specifying '-U root' and
the correct root password, I am unable to remove the job.
And when in permissive mode, I am still able to remove everyone's job without
being asked for a password.

This looks strange to me since I'd expect something like 'lprm: Job #00 does not
exist!' when trying to delete a job from a user who's domain is inaccessible. I
don't think lspp has a requirement about this, though - so just FYI.

With regards to "now MAC checks are being applied to this operation, so when in
enforcing mode, even when specifying '-U root' and the correct root password, I
am unable to remove the job."   I think its better to say RBAC checks are being
applied.  In enforcing mode, even with the correct password, users are unable to
delete other's jobs from the queue unless they are in a role which has
permissions to manage the queue.  When I gave the correct password from staff_r
I was not able to delete a job, but once changed to sysadm_r I was able to
remove the job.

As for permissive mode, I am still prompted for a password.  Although permissive
mode is not supported I'd still expect to see consistent behavior, perhaps you
could elaborate on how you setup your test in permissive mode.

(In reply to comment #22)
> As for permissive mode, I am still prompted for a password.  Although permissive
> mode is not supported I'd still expect to see consistent behavior, perhaps you
> could elaborate on how you setup your test in permissive mode.

Have you removed the 'AuthType Basic' from the Cancel job policy?

No I still have that there.  I was confused on this as well so I email'ed Tim
and this is what he said:

No.  Just set "AuthType Basic" or any other authentication scheme you
like, and the client will ask the server to use getsockopt(SO_PEERCRED)
if (a) it failed to authenticate using a certificate, (b) it is over an
AF_LOCAL socket, and (c) it is authenticating as the current user.

It is basically an extension of the certificates mechanism.

----

So with the patch Tim created we still need to have 'AuthType Basic' just that
the patch makes it so the server doesn't prompt for a password when you're not
masquerading as a different user.

Is the fix to bug #229673 not working as expected?  If that is the case, please
add a note to that bug report.

For *this* bug (bug #230613), 'AuthType Basic' is needed for any operations that
are to be authenticated (such as Cancel-Job), and the SO_PEERCRED patch
effectively by-passes the 'Basic' authentication similarly to the way a root
certificate (i.e. providing the contents of /var/run/cups/certs/0) does. 
However, I have not yet built a CUPS package for Red Hat Enterprise Linux 5
containing this patch.  This will come soon.

No, bug #229673 fixed and working as expected from my testing.

Have you got feedback from mainstream Cups about this one? This is one of two or
three packages that we are awaiting for the final (LSPP) version.

tested, 1:1.2.4-11.8 seems to fix this problem

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2007-1020.html