-
Notifications
You must be signed in to change notification settings - Fork 469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Policy CUPS-Add-Modify-Printer unlikly when using multiple policies #2525
Comments
CUPS.org User: pipitas No, it's not useless. What you can't do is to use a single operation only, and define a policy on it with a <Limit ...> section and expect the rest of operations to work like is defined in the "default" policy. What happens in reality is, that your single operation may silently amended by a section that works against your intentions. So when you define a custom policy, be sure to include one or more <Limit ...>... sections that describe exactly all the operations and their (different) limitations, and add another ... section, that describes exactly how the rest of operations should be affected by your custom policy. This works. |
CUPS.org User: mike And to add to what Kurt said, once you have added a printer or class, the CUPS-Add-Modify-Printer/Class operations use the printer's policy (not the default policy) to authorize the request. Thus it is possible to only allow one set of users to create a queue and another to maintain it. |
CUPS.org User: mike Reopening as a bug - not a feature request... [Reported via mailing list...] against the printer's policy to authorize the request, thus not doing what |
CUPS.org User: mike Fixed in Subversion repository. |
"str2525.patch": Index: scheduler/ipp.c--- scheduler/ipp.c (revision 6992) /*
- */
- }
@@ -941,18 +931,31 @@
pclass = cupsdAddClass(resource + 9);
if (ImplicitAnyClasses)
snprintf(newname, sizeof(newname), "%s@%s", resource + 9, pclass->hostname); @@ -984,6 +993,12 @@
@@ -2180,16 +2195,6 @@ /*
- */
- }
@@ -2213,18 +2218,31 @@
printer = cupsdAddPrinter(resource + 10);
if (ImplicitAnyClasses)
snprintf(newname, sizeof(newname), "%s@%s", resource + 10,
|
Version: 1.3-current
CUPS.org User: rojon
It's useless for instance, to grant access for CUPS-Add-Modify-Printer or CUPS-Add-Modify-Class to a named policy. For example, to restrict groups to modify only printers which belongs to their group / assigned policy. Even changing printer-settings will need these rights granted to CUPS-Add-Modify-Printer/Classes in a global (default) policy.
Would be nice to strip them down to the asigned policies.
The text was updated successfully, but these errors were encountered: