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

Re: Schema change for olcAccess rules.

Gavin Henry wrote:
Romain Komorn wrote: 
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.

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.

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?

Romain Komorn 

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


No point in moving it.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/