> Hallvard B Furuseth wrote:
>> ando(a)sys-net.it writes:
>>> On a related note, if this can be considered of general usefulness, LDAP
>>> specs would need to be changed in order to define a finer grain of
>>> attribute request; something like:
>>> empty or "*" ; all user, except attrs that need to be explicitly
>>> "+" ; all operational
>>> <all including attrs that need to be explicitly requested>
>> Would it be cleaner if slapo-cloak redefines the attributes to be
>> operational, or to behave as if they are? Maybe give them an
>> X-AS-OPERATIONAL extension? Or would that just mess up schema code,
>> things like attribute inheritance?
> I think things would mess up.
I'd also recommend *not* to turn user attribute types into operational
attribute types. This would certainly confuse schema-aware clients.
> Moreover, I see a number of features system administrators could ask
> for; e.g. hide attributes only when matching a URI (base, scope,
Well, that's something many overlays would benefit from.
In fact, based on recent modifications to slapo-constraint(5) and other
overlays, I'm considering the opportunity to introduce generic helpers
to parse and check this type of generic limitations.
> or based on size limit,
I meant: size of the attribute; only return values whose size does not
exceed a gien number of octets, unless explicitly requested.
> or based on client's identity and so.
That would be similar (not equal) to using ACLs. That was explicitly not
the case in the original inquiry.
Not exactly. We're discussing the issue of limiting what information
not explicitly requested should be returned. An administrator could
decide, say, that anonymous will not get any jpegPhoto, unless
explicitly requested. This is not ACL (in the stricter sense of what
access privilege an identity is granted), but rather resource access policy.
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497