Petr Viktorin wrote:
On 09/06/2013 02:46 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 09/05/2013 07:48 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
I have some notes and questions on (Control access of user
roles to server functions).
Right, I just want to know why it was proposed to add 2 ACIs for every

One for the container itself, one for the objects beneath it.

I don't see a straightforward way to allow access to both in a single
permission. (Currently, permissions need to be at $SUFFIX, so their
subtrees are specified by target.)


Right. I'm not sure you need to grant read,search,compare to the container. Have you tested that?

# Combining read rights

I think (read, search, compare) should be exposed in permission
as a single right. Or is there a reason to keep it split?

Yes, they are separate for a reason. Using only search and compare
common, but it isn't unheard of either. For example, to be able to
detect the
presence of an attribute you can provide just the search permission.

Wouldn't most users use the (read, search, compare) triple? It would
lower our
number of ACIs significantly if we do not have 3 permissions per each

There is nothing to prevent an ACI from containing multiple permissions.
I wasn't proposing that. But rolling these three logically into the same
thing in IPA I think is short-sighted.

See my other e-mail with my reasoning. I don't particularly care about
this issue, though.

# P.S.

I believe that we should strive to put our info about default
permissions, containers, settings, and the schema for each plugin in
actual plugin module, rather than it all being split across several
ldif/update files. This would make this data more manageable,
introspectable and consistent, expose dependencies between plugins,
make it possible to actually write self-contained plugins.
This should be done when the time comes for a new version of the

Well, my alarm bells are going off. This would require some significant
review each and every time any object is updated. Consider how many
times API.txt is overlooked, and it has no security implications.

Consider how many times the ldif or update files were overlooked.
API.txt is checked during every build, whereas ldif/update files not,
and are tedious to check.

We can of course add a similar file for ACIs, in fact I was planning to
do so. Any changes can be then reviewed both in the source and (like
now) in the resulting ldif. Also, the information would be in one place,
rather than in ldif (which doesn't apply on upgrades) and in update files.
I believe it would actually be better for security.

The plan at the time updates were added was to move absolutely everything out of ldif and into updates. It just never happened.

I can't say I'm a fan of programmatic ACI generation.

Well, I'm sure not going to write the ACIs for this feature by hand. It
would help I could actually polish, commit and integrate the script that
generates them.
In my book, programmatic generation is much better than copy+paste.

On the other hand, it becomes very easy to just rely on it and not closely examine the output.


Freeipa-devel mailing list

Reply via email to