Re: [Dorset] CUPS authentication question
Hi Tim On 09/12/13 12:57, Tim Waugh wrote: On Fri, 2013-12-06 at 14:10 +, Tim Allen wrote: Log on to CUPS Jobs web page as user1. All jobs (user1 and any other user) show Name Unknown, User Withheld for each job. This is correct for default JobPrivateValues (from manual, The default values are job-name, job-originating-host-name, and job-originating-user-name.) But incorrect for JobPrivateAccess (should be @OWNER, @SYSTEM). In fact, it doesn't matter what we put for JobPrivateAccess (all, user1, anything else), the result is the same - access is barred. This works as expected for me: the owning user (user1 in your case) gets to see their own job metadata, but not anyone else's, on the basis of their provided 'requesting-user-name' value. In that, that's the default configuration. cups-1.7.0-6.fc20.x86_64 Looks like an issue in 1.5 in Debian Wheezy then, subsequently fixed. FWIW, I don't think the '/jobs' location restriction is sufficient to password-protect all cases of getting job information. CUPS-Get-Jobs is performed on the printer URI, for instance, and CUPS-Get-Job-Attributes can be performed on a printer URI with a 'job-id' attribute provided. There are also subscriptions to cover. OK - thanks for pointing this out. Cheers Tim -- Next meeting: Bournemouth, Tuesday, 2014-01-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] CUPS authentication question
On Fri, 2013-12-06 at 14:10 +, Tim Allen wrote: Here's the relevant sections of cupsd.conf: DefaultAuthType Basic WebInterface Yes Location / Order allow,deny Allow @LOCAL /Location Location /jobs AuthType Default Require valid-user Order allow,deny Allow @LOCAL /Location Policy default JobPrivateAccess default JobPrivateValues default SubscriptionPrivateAccess default SubscriptionPrivateValues default Log on to CUPS Jobs web page as user1. All jobs (user1 and any other user) show Name Unknown, User Withheld for each job. This is correct for default JobPrivateValues (from manual, The default values are job-name, job-originating-host-name, and job-originating-user-name.) But incorrect for JobPrivateAccess (should be @OWNER, @SYSTEM). In fact, it doesn't matter what we put for JobPrivateAccess (all, user1, anything else), the result is the same - access is barred. This works as expected for me: the owning user (user1 in your case) gets to see their own job metadata, but not anyone else's, on the basis of their provided 'requesting-user-name' value. In that, that's the default configuration. cups-1.7.0-6.fc20.x86_64 FWIW, I don't think the '/jobs' location restriction is sufficient to password-protect all cases of getting job information. CUPS-Get-Jobs is performed on the printer URI, for instance, and CUPS-Get-Job-Attributes can be performed on a printer URI with a 'job-id' attribute provided. There are also subscriptions to cover. Tim. */ signature.asc Description: This is a digitally signed message part -- Next meeting: Bournemouth, Tuesday, 2014-01-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] CUPS authentication question
On Thu, 2013-12-05 at 21:02 +, Tim Allen wrote: Yes, so my understanding is that any job not owned by the authenticated user (who is not a member of lpadmin) should show as withheld, No -- the JobPrivateValues attributes would. But they are none, so JobPrivateAccess has no effect. Think of it like chmod 755 * -- 755 would be JobPrivateAccess, * would be JobPrivateValues. Tim. */ signature.asc Description: This is a digitally signed message part -- Next meeting: Bournemouth, Tuesday, 2014-01-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] CUPS authentication question
Hi Tim On 06/12/13 10:04, Tim Waugh wrote: On Thu, 2013-12-05 at 21:02 +, Tim Allen wrote: Yes, so my understanding is that any job not owned by the authenticated user (who is not a member of lpadmin) should show as withheld, No -- the JobPrivateValues attributes would. But they are none, so JobPrivateAccess has no effect. Think of it like chmod 755 * -- 755 would be JobPrivateAccess, * would be JobPrivateValues. Yes, you're right. JobPrivateValues default and JobPrivateAccess default should do what I wanted. It looks like JobPrivateAccess is broke (basically ignored) in 1.5, setting JobPrivateValues none at least gets back to pre-1.5 behaviour. Cheers Tim -- Next meeting: Bournemouth, Tuesday, 2014-01-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] CUPS authentication question
On Fri, 2013-12-06 at 10:49 +, Tim Allen wrote: It looks like JobPrivateAccess is broke (basically ignored) in 1.5, setting JobPrivateValues none at least gets back to pre-1.5 behaviour. I'm not sure why you think it isn't working. Can you give an example that doesn't behave as you expect? (I've just re-read all your messages in this thread, and I don't see one that wasn't explained by my 'chmod' analogy.) Tim. */ signature.asc Description: This is a digitally signed message part -- Next meeting: Bournemouth, Tuesday, 2014-01-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] CUPS authentication question
Hi Tim On 06/12/13 12:09, Tim Waugh wrote: On Fri, 2013-12-06 at 10:49 +, Tim Allen wrote: It looks like JobPrivateAccess is broke (basically ignored) in 1.5, setting JobPrivateValues none at least gets back to pre-1.5 behaviour. I'm not sure why you think it isn't working. Can you give an example that doesn't behave as you expect? (I've just re-read all your messages in this thread, and I don't see one that wasn't explained by my 'chmod' analogy.) Here's the relevant sections of cupsd.conf: DefaultAuthType Basic WebInterface Yes Location / Order allow,deny Allow @LOCAL /Location Location /jobs AuthType Default Require valid-user Order allow,deny Allow @LOCAL /Location Policy default JobPrivateAccess default JobPrivateValues default SubscriptionPrivateAccess default SubscriptionPrivateValues default Log on to CUPS Jobs web page as user1. All jobs (user1 and any other user) show Name Unknown, User Withheld for each job. This is correct for default JobPrivateValues (from manual, The default values are job-name, job-originating-host-name, and job-originating-user-name.) But incorrect for JobPrivateAccess (should be @OWNER, @SYSTEM). In fact, it doesn't matter what we put for JobPrivateAccess (all, user1, anything else), the result is the same - access is barred. OK, test2, let's get rid of the jobs location but require authentication to the server whole: change cupsd.conf to: DefaultAuthType Basic WebInterface Yes Location / AuthType Default Require valid-user Order allow,deny Allow @LOCAL /Location Policy default JobPrivateAccess default JobPrivateValues default SubscriptionPrivateAccess default SubscriptionPrivateValues default With this, everything works as expected (although of course now we need to be a valid user to print). Logging on to CUPS web interface as user1, every print job owned by user1 is fully shown, all other jobs show Name Unknown, User Withheld. So there's a problem with JobPrivateAccess picking up on Location /jobs (whereas JobPrivateValues does correctly recognise that location). Cheers Tim -- Next meeting: Bournemouth, Tuesday, 2014-01-07 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] CUPS authentication question
Hi Tim On 03/12/13 16:39, Tim Waugh wrote: On Tue, 2013-12-03 at 16:25 +, Tim Allen wrote: Hi All Playing around with CUPS 1.5.3 on Debian Squeeze. 1.5 has a nice feature to hide job details on the web interface via JobPrivateAccess and JobPrivateValues. With the following in cupsd.conf: # Restrict access to the server... Location / AuthType Default Require valid-user Order allow,deny Allow @LOCAL /Location individual users must log in to the web interface and only see their own job details, but members of SystemGroup can see all job details - nice! However, with the AuthType Default Require valid-user lines, I can't print from remote machines without getting into further authentication complications. I'm guessing I need to use a different Location directive that only applies to the jobs pages of the web interface - can anyone advise? I think you really want a policy modification. That specifies the authentication requirements based on the operation, not the location/resource. Look at the Policy authenticated.../Policy section. I think those defaults might be what you want. You can set the policy on a per-queue basis. Thanks, that's pointed me in the right direction. But the remaining question is, how do I get the Policy authenticated to be triggered? With Policy default # Job/subscription privacy... JobPrivateAccess default JobPrivateValues default /Policy Policy authenticated # Job/subscription privacy... JobPrivateAccess default JobPrivateValues none /Policy I assume I need to require authentication to access Jobs. I've tried a Location /admin/log AuthType Default Require valid-user /Location section, but that didn't bring up a user/password request. (Changing JobPrivateValues to none in the default policy unhides the details, proving that policy is being run). Cheers Tim -- Next meeting: Bournemouth, Tuesday, 2013-12-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] CUPS authentication question
On 04/12/13 09:38, Tim Allen wrote: Hi Tim On 03/12/13 16:39, Tim Waugh wrote: On Tue, 2013-12-03 at 16:25 +, Tim Allen wrote: Hi All Playing around with CUPS 1.5.3 on Debian Squeeze. 1.5 has a nice feature to hide job details on the web interface via JobPrivateAccess and JobPrivateValues. With the following in cupsd.conf: # Restrict access to the server... Location / AuthType Default Require valid-user Order allow,deny Allow @LOCAL /Location individual users must log in to the web interface and only see their own job details, but members of SystemGroup can see all job details - nice! However, with the AuthType Default Require valid-user lines, I can't print from remote machines without getting into further authentication complications. I'm guessing I need to use a different Location directive that only applies to the jobs pages of the web interface - can anyone advise? I think you really want a policy modification. That specifies the authentication requirements based on the operation, not the location/resource. Look at the Policy authenticated.../Policy section. I think those defaults might be what you want. You can set the policy on a per-queue basis. Thanks, that's pointed me in the right direction. But the remaining question is, how do I get the Policy authenticated to be triggered? With Policy default # Job/subscription privacy... JobPrivateAccess default JobPrivateValues default /Policy Policy authenticated # Job/subscription privacy... JobPrivateAccess default JobPrivateValues none /Policy I assume I need to require authentication to access Jobs. I've tried a Location /admin/log AuthType Default Require valid-user /Location section, but that didn't bring up a user/password request. (Changing JobPrivateValues to none in the default policy unhides the details, proving that policy is being run). Found the solution (I'd missed the /jobs location in the documentation): Location /jobs AuthType Default Require valid-user Order allow,deny Allow @LOCAL /Location Policy default # Job/subscription privacy... JobPrivateAccess default JobPrivateValues default /Policy Policy authenticated # Job/subscription privacy... JobPrivateAccess default JobPrivateValues none /Policy Thanks, Tim, for pointing me in the right direction. Cheers Tim -- Next meeting: Bournemouth, Tuesday, 2013-12-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] CUPS authentication question
On 04/12/13 09:57, Tim Allen wrote: On 04/12/13 09:38, Tim Allen wrote: Hi Tim On 03/12/13 16:39, Tim Waugh wrote: On Tue, 2013-12-03 at 16:25 +, Tim Allen wrote: Hi All Playing around with CUPS 1.5.3 on Debian Squeeze. 1.5 has a nice feature to hide job details on the web interface via JobPrivateAccess and JobPrivateValues. With the following in cupsd.conf: # Restrict access to the server... Location / AuthType Default Require valid-user Order allow,deny Allow @LOCAL /Location individual users must log in to the web interface and only see their own job details, but members of SystemGroup can see all job details - nice! However, with the AuthType Default Require valid-user lines, I can't print from remote machines without getting into further authentication complications. I'm guessing I need to use a different Location directive that only applies to the jobs pages of the web interface - can anyone advise? I think you really want a policy modification. That specifies the authentication requirements based on the operation, not the location/resource. Look at the Policy authenticated.../Policy section. I think those defaults might be what you want. You can set the policy on a per-queue basis. Thanks, that's pointed me in the right direction. But the remaining question is, how do I get the Policy authenticated to be triggered? With Policy default # Job/subscription privacy... JobPrivateAccess default JobPrivateValues default /Policy Policy authenticated # Job/subscription privacy... JobPrivateAccess default JobPrivateValues none /Policy I assume I need to require authentication to access Jobs. I've tried a Location /admin/log AuthType Default Require valid-user /Location section, but that didn't bring up a user/password request. (Changing JobPrivateValues to none in the default policy unhides the details, proving that policy is being run). Found the solution (I'd missed the /jobs location in the documentation): Location /jobs AuthType Default Require valid-user Order allow,deny Allow @LOCAL /Location Policy default # Job/subscription privacy... JobPrivateAccess default JobPrivateValues default /Policy Policy authenticated # Job/subscription privacy... JobPrivateAccess default JobPrivateValues none /Policy Thanks, Tim, for pointing me in the right direction. Cheers Tim Thank you for documenting that last step and showing us the complete solution. Peter M. -- Next meeting: Bournemouth, Tuesday, 2013-12-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] CUPS authentication question
On Wed, 2013-12-04 at 09:38 +, Tim Allen wrote: Thanks, that's pointed me in the right direction. But the remaining question is, how do I get the Policy authenticated to be triggered? With Which policy is used is set on a per-queue basis. It's the printer-op-policy. So to get a particular queue to use the authenticated policy, do this: lpadmin -p queue -o printer-op-policy=authenticated Tim. */ signature.asc Description: This is a digitally signed message part -- Next meeting: Bournemouth, Tuesday, 2013-12-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
[Dorset] CUPS authentication question
Hi All Playing around with CUPS 1.5.3 on Debian Squeeze. 1.5 has a nice feature to hide job details on the web interface via JobPrivateAccess and JobPrivateValues. With the following in cupsd.conf: # Restrict access to the server... Location / AuthType Default Require valid-user Order allow,deny Allow @LOCAL /Location individual users must log in to the web interface and only see their own job details, but members of SystemGroup can see all job details - nice! However, with the AuthType Default Require valid-user lines, I can't print from remote machines without getting into further authentication complications. I'm guessing I need to use a different Location directive that only applies to the jobs pages of the web interface - can anyone advise? Would Location /jobs be the way to go or is that going to introduce further problems elsewhere? Thanks Tim -- Next meeting: Bournemouth, Tuesday, 2013-12-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
Re: [Dorset] CUPS authentication question
On Tue, 2013-12-03 at 16:25 +, Tim Allen wrote: Hi All Playing around with CUPS 1.5.3 on Debian Squeeze. 1.5 has a nice feature to hide job details on the web interface via JobPrivateAccess and JobPrivateValues. With the following in cupsd.conf: # Restrict access to the server... Location / AuthType Default Require valid-user Order allow,deny Allow @LOCAL /Location individual users must log in to the web interface and only see their own job details, but members of SystemGroup can see all job details - nice! However, with the AuthType Default Require valid-user lines, I can't print from remote machines without getting into further authentication complications. I'm guessing I need to use a different Location directive that only applies to the jobs pages of the web interface - can anyone advise? I think you really want a policy modification. That specifies the authentication requirements based on the operation, not the location/resource. Look at the Policy authenticated.../Policy section. I think those defaults might be what you want. You can set the policy on a per-queue basis. Tim. */ signature.asc Description: This is a digitally signed message part -- Next meeting: Bournemouth, Tuesday, 2013-12-03 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread on mailing list: mailto:dorset@mailman.lug.org.uk How to Report Bugs Effectively: http://goo.gl/4Xue
