[cups-devel] Sharing printers ACLs with remote client (f.e. cups-browsed) - opinions?

[Zdenek Dohnal]

Hi everyone,

I'm currently working on feature for cups-browsed daemon, which would
ask cupsd in IPP request (with operation CUPS-Get-Printers, with all
necessary attributes and with requesting-user-name-allowed and
requesting-user-name-denied attributes in requested-attributes field)
and would create local print queue with ACL from remote CUPS -
basically, remote CUPS would share printer ACL with client
(cups-browsed) and client would issue print queue creation with ACL to
local CUPS daemon.

It seems a print queue on remote server needs to have allowed user
'remroot' in its ACL to get printer into the IPP response (because
cups-browsed runs as root, so there is user 'root' in the IPP request's
'requesting-user-name' attribute, which is later replaced by 'remroot'
in cups daemon). If remroot is not in allowed users, then the printer is
not added into IPP response.

I would like to ask for opinion on the feature:

1) Is it even reasonable to have such feature? Like will it bring
problems or security concerns? I can only think of some scenarios where
two users on different machines have the same names and the program will
not recognize the difference between them (if one has the right to print
and other does not), but IMHO it is more admin error...

2) Is it good to have 'remroot' user in printer's ACL?

3) Would the feature need a change in CUPS code? IMO the feature does
not need any change to CUPS code, but maybe I'm missing something...

4) Is it defined in RFC/PWG docs how many user names can be in
requesting-user-name-allowed/denied attributes? I only found definition
'1setOf name(127)', which IIUC means X number of usernames of max length
127.

5) Any other opinions/concerns?


Thank you for reading this far and thanks for answers in advance!

Have a nice day,

Zdenek

-- 
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C