Re: Using groupOfNames (or similar) for UNIX groups and netgroups (was Re: DBIS commentary)

This is a multi-part message in MIME format.
--===============6509327132969940954==
Content-Type: multipart/alternative;
 boundary="------------040505020607040501020002"

This is a multi-part message in MIME format.
--------------040505020607040501020002
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 12/2/2015 9:21 AM, Simo Sorce wrote:
> On Tue, 2015-12-01 at 18:21 -0800, Jordan Brown wrote:
>> [draft-masarati-ldap-deref-00] is indeed very interesting. I don't
>> immediately see how it helps with the type-safety problem, though.
>> Am I missing something?
> The idea is that you can get all data up at once including objectclass
> and then you can simply drop results that do not have the right
> objectclass value.
> It is a little more wasteful than being able to specify a secondary
> filter (that would probably be a great addition to the draft), for the
> search done on the attribute of the group entry, but it is still good
> enough to efficiently get results as well as easily weed off unwanted
> ones.

OK, sure.  (Better still would be to have some way to tell the directory to limit 
the types allowed.)
>> Yes, and I infer that there's corresponding omissions in other parts of the 
>> standard. In the getgrent description, the standard describes omitting this 
>> information on the basis of security restrictions. Omitting the data there 
>> would not help security at all if you could immediately turn around and request 
>> it through getgrname and getgrgid. Meeting the security need would require 
>> having the restrictions in both places. 
> True, but are not doing this for security reasons, we are just taking
> the fact that omissions are permissible as a blanket permission to omit
> results, and clients should be prepared to deal with that.

Right, but the standard describes it in terms of security.

> After all the texts are vague and you could think that the security
> measure expressed here is about not revealing group names.

It explicitly mentions editing the list of members (emphasis added):

http://pubs.opengroup.org/onlinepubs/9699919799/functions/getgrent.html

    An implementation that provides extended security controls may impose further
    implementation-defined restrictions on accessing the group database. In
    particular, the system may deny the existence of some or all of the group
    database entries associated with groups other than those groups associated
    with the caller *and may omit users other than the caller from the list of
    members of groups in database entries that are returned*.


> The fact you can easily scan the whole group ID space is just the
> annoying consequence of the fact most systems do not have a randomized
> ID assignment policy and have a pretty limited ID space at just 32bit of
> size or less. But hey, that's not my fault! :-)

That too, but I was thinking about the list-of-members part... if you have a 
security reason for keeping the list of members hidden, it wouldn't do you any 
good to hide it from getgrent when the caller could then immediately retrieve it 
using getgrgid.

>> We could address it through introducing a new object class (and here I include
>> just grabbing "group" from AD or "groupOfNames" from RFC2307bis-02, not just
>> creating a wholly new one), or by changing the definition.  This is one of those
>> cases where I'd say that breaking formal compatibility might well be appropriate.
> Yes, it would be nice to change the class, because it is forward safe to
> do so, if you created objects when the MUST was in place, nothing breaks
> if you relax the constraint to MAY, at least from the POV of data
> consistency in the directory.
>
> And I never found any software the specifically rely on the fact you
> can't delete the last member attribute from a group for something.
> Actually usually I saw software that had to use workarounds like adding
> the group dn to itself (and concealing the self-reference in the UI)
> when an admin wants to remove the last member but not remove the whole
> group.

The potential problem is a consumer that knows that the "member" attribute MUST be 
present, and freaks out if it isn't.


--------------040505020607040501020002
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 12/2/2015 9:21 AM, Simo Sorce wrote=
:<br>
    </div>
    <blockquote cite=3D"mid:[email protected]"
      type=3D"cite">
      <pre wrap=3D"">On Tue, 2015-12-01 at 18:21 -0800, Jordan Brown wrot=
e:
</pre>
      <blockquote type=3D"cite">
        [draft-masarati-ldap-deref-00] is indeed very interesting. I
        don't<br>
        <pre wrap=3D"">immediately see how it helps with the type-safety =
problem, though.
Am I missing something?
</pre>
      </blockquote>
      <pre wrap=3D"">
The idea is that you can get all data up at once including objectclass
and then you can simply drop results that do not have the right
objectclass value.
It is a little more wasteful than being able to specify a secondary
filter (that would probably be a great addition to the draft), for the
search done on the attribute of the group entry, but it is still good
enough to efficiently get results as well as easily weed off unwanted
ones.</pre>
    </blockquote>
    <br>
    OK, sure.=C2=A0 (Better still would be to have some way to tell the
    directory to limit the types allowed.)<br>
    <blockquote cite=3D"mid:[email protected]"
      type=3D"cite">
      <blockquote type=3D"cite">
        Yes, and I infer that there's corresponding omissions in other
        parts of the standard. In the getgrent description, the standard
        describes omitting this information on the basis of security
        restrictions. Omitting the data there would not help security at
        all if you could immediately turn around and request it through
        getgrname and getgrgid. Meeting the security need would require
        having the restrictions in both places.
      </blockquote>
      <pre wrap=3D"">
True, but are not doing this for security reasons, we are just taking
the fact that omissions are permissible as a blanket permission to omit
results, and clients should be prepared to deal with that.</pre>
    </blockquote>
    <br>
    Right, but the standard describes it in terms of security.<br>
    <br>
    <blockquote cite=3D"mid:[email protected]"
      type=3D"cite">
      <pre wrap=3D"">After all the texts are vague and you could think th=
at the security
measure expressed here is about not revealing group names.</pre>
    </blockquote>
    <br>
    It explicitly mentions editing the list of members (emphasis added):<=
br>
    <br>
<a class=3D"moz-txt-link-freetext" href=3D"http://pubs.opengroup.org/onli=
nepubs/9699919799/functions/getgrent.html">http://pubs.opengroup.org/onli=
nepubs/9699919799/functions/getgrent.html</a><br>
    <blockquote>
      <p>An implementation that provides extended security controls may
        impose further implementation-defined restrictions on accessing
        the group database. In particular, the system may deny the
        existence of some or all of the group database entries
        associated with
        groups other than those groups associated with the caller <b>and
          may omit users other than the caller from the list of members
          of
          groups in database entries that are returned</b>.</p>
    </blockquote>
    <br>
    <blockquote cite=3D"mid:[email protected]"
      type=3D"cite">
      <pre wrap=3D"">The fact you can easily scan the whole group ID spac=
e is just the
annoying consequence of the fact most systems do not have a randomized
ID assignment policy and have a pretty limited ID space at just 32bit of
size or less. But hey, that's not my fault! :-)</pre>
    </blockquote>
    <br>
    That too, but I was thinking about the list-of-members part... if
    you have a security reason for keeping the list of members hidden,
    it wouldn't do you any good to hide it from getgrent when the caller
    could then immediately retrieve it using getgrgid.<br>
    <br>
    <blockquote cite=3D"mid:[email protected]"
      type=3D"cite">
      <blockquote type=3D"cite">
        <pre wrap=3D"">We could address it through introducing a new obje=
ct class (and here I include=20
just grabbing "group" from AD or "groupOfNames" from RFC2307bis-02, not j=
ust=20
creating a wholly new one), or by changing the definition.  This is one o=
f those=20
cases where I'd say that breaking formal compatibility might well be appr=
opriate.
</pre>
      </blockquote>
      <pre wrap=3D"">
Yes, it would be nice to change the class, because it is forward safe to
do so, if you created objects when the MUST was in place, nothing breaks
if you relax the constraint to MAY, at least from the POV of data
consistency in the directory.

And I never found any software the specifically rely on the fact you
can't delete the last member attribute from a group for something.
Actually usually I saw software that had to use workarounds like adding
the group dn to itself (and concealing the self-reference in the UI)
when an admin wants to remove the last member but not remove the whole
group.
</pre>
    </blockquote>
    <br>
    The potential problem is a consumer that knows that the "member"
    attribute MUST be present, and freaks out if it isn't.<br>
    <br>
  </body>
</html>

--------------040505020607040501020002--


--===============6509327132969940954==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext

--===============6509327132969940954==--