> The benefit is "not wrecking server performance".
>
> Even in freeipa, memberOf is not hidden ... I can't think of any situation where
it is hidden ...
>
> Today, the inverse risk exists. You can't read member from group hidden, but you
can see user X is memberof: hidden. But we don't seem to worry about "that"
for access controls.
>
> Or even nsRoles? We also don't seem to worry about dynamic groups for that. Or
cos templates. Or many of the other ways we generate attributes .... There is ALWAYS a
trade here of exposing infomation via a generated attribute that a user otherwise
couldn't ask for
>
> If someone truly was "that worried" about access to this attribute they
need to disable memberOf and this inchain control.
I think that the user sending the request
'(member:1.2.840.113556.1.4.1941:=uid=foo,dc=com)' should get the same result as
if he is iterating through 'member' step by step (e.g sending
'(member=uid=foo,dc=com)' -> G2, then sending '(member=G2)'-> NULL),
the response should only be G2.
I agree that access control that limits access to 'member' but not
'memberof' will reveal a security issue but it is because of badly designed access
control, not because of access control not being enforced.
IMHO we have two aspects to evaluate the benefit of the shortcut: candidate list and
access control.
The use of the shortcut, gives a faster lookup of the candidates than following the
links.
Access control is faster while following the links than on a raw list of candidates (need
to recreate the graph).
I think this is not correct, and I think you are thinking about edge case problems that
pretty much don't exist. FreeIPA makes all groups world readable. AD does too. Most
directory systems ship with an access control to allow full read to all groups.
Our memberof already nests groups. So we can look at a user and see all groups they are
memberof, even if we can't read the groups. So we are not disclosing any extra
information here. In freeipa this is also true.
Ultimately it's up to you. So long as this feature is disabled by default so it
can't be used by most people, I'm not bothered (bonus marks if you have it behind
a ./configure feature flag so SUSE doesn't even need to compile it). I've given
you my warning about the (serious) performance risks which will only compound with
freeipa's already poor performance in AD trust mode.
--
Sincerely,
William Brown
Sesion Software Engineer,
Identity and Access Management
SUSE Labs, Australia