[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Schema change for olcAccess rules.

Perhaps this is more of a development question than a usage question,
but I thought this would be a decent forum to see if the idea gets any
feedback (positive or negative).

I don't know how much others manipulate their olcAccess, or even if most
people just maintain them in slapd.conf and restart slapd when
necessary. I'm treating olcAccess entries more or less like firewall
rules, adding and removing on the fly, thanks to the olcAccess
attributes in backend DB definitions.

To me, it would seem a lot more convenient if the olcAccess in the
backend DB definition pointed to a objectClass groupOfOlcAccess (for
lack fo a better term).

I don't see anything in this proposal that increases convenience. Perhaps you first need to define what's "inconvenient" in the current approach.

The current approach isn't inconvenient. It's sensible enough, I didn't mean to say it needs to be fixed, but I do think it could be improved. I think there's a difference.

Obviously, how useful this kind of change would be depends on how often
people update their ACLs. In my case, I can see it happening often
enough that I'd prefer to add/delete cn's or "whoaccess" attributes,
rather than editing olcAccess attributes in the backend config. I'd want
the backend config to be fairly static, as opposed to the ACLs in my
environment which would be fairly dynamic.


Feel free to tell me it's a terrible idea. I may not know enough
background information about how slapd works and how this type of schema
change would affect performance.

OK, it's a terrible idea. Performance isn't the prime concern with access controls, security is. The point is that access controls apply to specific database instances. Moving them off to completely independent entries, introducing a level of indirection, hides/obscures their relevance.

I disagree that it obscures the access control's reference. It simply creates a "pointer" to the list of access controls that apply to this database instance. I don't see much obscurity there is in looking up the access list that's pointed to, versus going through the olcAccess attributes of the database entry.

When you look at network switching ACLs, it's not uncommon to find cases where you define ACLs separately, and subsequently bind/apply them to network ports. If you take iptables as an example, you can get a similar effect by running traffic through different tables based on criteria like source IP, interface, port, etc.

One thing I could see as an added benefit would be the ability to apply the same ACL set to different database instances, but that may not improve security.

Obviously, OpenLDAP isn't a network switch, but that kind of ACL definition and binding makes sense to me, so I'm likely biased towards it.

That's the downside. I don't really see your suggested upside either, an attribute is edited either way. What difference does it make in terms of static vs dynamic whether the attribute is in one place or a different place?

I'll be a little 'dramatic' here. I tend to look at any change as a potential "threat" to my network's stability and security. As such, on any given change, I like to try and impact as little as I can get away with.

When I say that the database entry configuration is 'static', I mean that virtually all the attributes in the entry will remain the same indefinitely (beyond the original setup/definition).

I would consider changes to attributes like the olcRootDN|PW, or olcIndex, maybe, but I would definne those as pretty "major" changes that I don't anticpate making often, if at all.

Changes to the olcAccess attributes, on the other hand, I consider 'dynamic' because I plan to actually modify these fairly often. So to me, there is a very distinct difference between attributes that I want to call 'static' versus 'dynamic'. Going a little further still, I can also imagine that, when looking at olcAccess entries, I'm likely to change the 'who-access' more often than the 'what'.

When I look at a 'change' (ie: granting/revoking access to data), I tend to look at what collateral damage might occur. If I modify the olcAccess attribute of a database entry, I look at it as modifying the database entry itself. On the other hand, if I modify an olcAccess entry in a groupOfOlcAccess that is separate from the database entry, the worst that can happen is that the groupOfOlcAccess will be affected. Going a level deeper, if I modify a "who-access" attribute in an olcAccess entry, the worst case is that that olcAccess entry is affected.

So in an order of preference from most to least, I'd rather:

1- modify one 'who-access' attribute of an olcAccess entry
2- modify one 'what' attribute of an olcAccess entry
3- add/remove an olcAccess entry in a groupOfOlcAccess
4- modify an attribute on the database entry to point to a specific
groupOfOlcAccess
5- modify an olcAccess attribute in a database entry.

Naturaly, if I follow the "Don't do anything stupid." rule, it doesn't really matter whether the schema remains the way it is now, or takes on a form closer to what I suggested.

I would start a new thread (not hijacking an existing one) and resend to
-devel.

I'm guilty there. I'd just sent my email when I realized replying and changing the subject doesn't clear out headrers. My apologies.

My apologies also for the length of the email. Hopefully some/most of it was comprehensible enough. I know that a lot of it hinges strictly on opinion about how OpenLDAP looks from a user/admin point of view, so mine is probably all too subjective and personal.

Romain Komorn