Re: [ldapext] LDAP work at IETF...

[Mark R Bannister <[e-mail]>]

On 28/01/2015 17:51, Michael Ströder wrote:
> Mark R Bannister wrote:
>> On 27/01/2015 22:14, Michael Ströder wrote:
>>>> I think if people
>>>> started looking deeper into the DBIS internet drafts,
>>> I've looked into your drafts. But it differs very much from what I'm after. We
>>> had this discussion before: IMO netgroups must die, die, die...
>> This contradicts your earlier assertion that clients are hard-coded.  In the
>> same vein, clients are hard-coded to use netgroups, ergo netgroups cannot
>> "die, die, die".
> No contradiction, since IMO one can easily avoid using netgroups completely.

And use what instead?  When one needs to group together users and hosts 
in logical units,
what other pervasive choices are there?

> With my approach the ACLs on the LDAP server sort out what clients can
> actually see. Therefore you get the flexible access control without the client
> having to enforce e.g. login access control locally based on netgroups.

Ah, I see, so you're talking specifically of access control.  Yes, if 
all netgroups are there to do
is access control, then you can offload that as ACLs on the LDAP 
server.  But what about the
netgroups that are there to define application roles?

>
>> Rather than attempting to kill off something that is used extensively, and has
>> actually proved to be very useful in large UNIX/Linux estates (if a bit
>> clunky), I've embraced them, rationalised them, defined them in a neater and
>> queryable format, and complemented them with netservices.
> I'd avoid them and convert access control rules based on netgroups into
> another schema and let the LDAP server's ACL work through the data.

Agreed, great for access control.  But I don't see how that will work 
for the other netgroup
use-cases.

>> Apart from netgroups, which you are not a fan of, how else does DBIS differ
>> from what you're after?
> My main objective is that not the client system evaluates all the stuff. The
> client system should not see data not usable on the system. The client system
> acts as a dumb RFC2307(bis) and sudo-ldap client. Of course the client system
> still enforces file access permissions etc. locally.
>

I agree with you on that point.  Perhaps I could take a similar approach 
with DBIS.  I'm interested,
today the NSS library on Linux hosts does not have the identity of the 
requester.  It is quite normal
for there to be a service account used in the LDAP bind, or perhaps even 
an anonymous bind.
The LDAP server can then only usefully filter with ACLs data that is 
restricted to specific hosts,
but not to specific users.  So you are only solving half the problem, right?

Best regards,
Mark.