Beginner's problem with authentication policyin 1.3.0

John A. Murdie john at cs.york.ac.uk
Fri Nov 23 08:37:53 PST 2007


> John A. Murdie wrote:
> > ...
> > I've not seen an illustration anywhere of how this looks like to
>  > the user of one of these untrusted clients - for instance in the
>  > GUI of a Mac OS X client.
>
> Kerberized printing is not supported on Mac OS X 10.4.x.
>
> > I obtained a MacBook with OS X 10.4.10 (and fully up-to-date with
>  > software updates) to try this out. I decided to try an initial
>  > Location directive which Allow-s all the subnets in use, and the
>  > to have two Limit-s in the default Policy, one for the trusted
>  > subnet and one for the untrusted subnet:
> >
> >  <Limit Send-Document ...>
> >     Allow from trusted
> >     Order deny,allow
> >   </Limit>
> >
> >   <Limit Send-Document ...>
> >     Allow from untrusted
> >     Require user @OWNER @SYSTEM
> >     Order deny,allow
> >   </Limit>
>
> You really want to use:
>
>      <Limit Send-Document ...>
>        Order allow,deny
>        Allow from trusted
>        Require user @OWNER @SYSTEM
>        AuthType Default
>        Satisfy any
>      </Limit>
>
> ...
> --
> ______________________________________________________________________
> Michael R Sweet                        Senior Printing System Engineer
>

A belated thank you.

(We have ended up using 'DefaultAuthType Basic' because of the upset we would have caused by requiring all our laptop users to configure for Kerberos immediately. Our CUPS server uses pam_kerberos to authenticate users, which is a reasonable first stab at this business.)

For completeness of this thread, what I chose in the end, which works, was (substituting appropriate IP network base addresses for 'desktops' and for 'laptops', and an appropriate 'subnet-mask'):

...

DefaultAuthType Basic

...

<Location />
  Order allow,deny
  Allow from @LOCAL
  Allow from desktops/subnet-mask
  Allow from laptops/subnet-mask
  Encryption Required
</Location>

...

# Set the default printer/job policies...
<Policy default>
  # Job-related operations must be done by the owner or an adminstrator...

  # Staff desktops trusted, laptops must authenticate.
  <Limit Create-Job Print-Job Send-Document Send-URI>
   Order allow,deny
   Allow from desktops/subnet-mask
   Require valid-user
   Satisfy any
  </Limit>
  <Limit Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job CUPS-Move-Job>
    Order allow,deny
    Require user @OWNER @SYSTEM
  </Limit>

The one MAJOR problem I have is that the username that CUPS takes, of course, is that of the submitting user on the laptop, which may be different from the authenticated organisational username - and the laptop username appears on job headers and also gets to printer page accounting systems such as PyKota. This is of course bad, bad, bad; one can charge one's printing to others merely by creating oneself an account in any name one likes on one's laptop. Here this would be monetary theft.

A solution would be for CUPS to force the internal username to that of the authenticated user. (Would this ever not be required? If so, a boolean cupsd.conf directive needs to be added.) I'll have to think a bit more to decide how difficult this might be and whether there might be a better solution.

John A. Murdie




More information about the cups mailing list