[sudo-workers] Add support for DBIS netservices

[Todd C. Miller]

On Tue, 25 Aug 2015 07:09:34 -0000, "Bannister, Mark" wrote:

> Ok, I see, so the DBIS backend would go into the sudoers plugin.

Yes.

> So you need a simple and efficient way of getting a list of all netgroups
> that a user is a member of, is that what you're saying?

Correct.

> I've made it slightly easier to search netgroups in DBIS by adding the
> 
> netgroupUser and netgroupHost
> attributes<http://sourceforge.net/p/dbis/wiki/Map%20Entries/>, but it's not a
> single query
> 
> because netgroups can include other netgroups.  Unless there is
> an extended operation supported by the directory server that will
> do that type of search for you.  That may be what you are alluding to
> in the next paragraph.

Sudo's existing LDAP netgroup query code handles nested netgroups
itself by doing recursive matches on memberNisNetgroup.  I wish it
was simpler.

> The DBIS caching daemon hides away the complexity of the LDAP search
> operations from the caller.  There is a single lookup function you run from
> the DBIS library to get the information you need, and dbis-cachemgr is
> responsible for finding the information.  It may be stored in a variety of
> places in the DIT, and may be subject to transformation rules, depending
> on how the user has configured their maps, so it is not really possible to
> bypass dbis-cachemgr and construct an LDAP search operation yourself.

Much of the complexity in sudo's ldap code comes from supporting
disparate LDAP libraries.  Sudo does need to do more than simpler
name/value lookups however.  It's not clear to me that DBIS can
support that.

> I'm not sure I understand the problem with OpenLDAP and RFC2307bis
> 
> you mention.  I've found one
> commit<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=14d
> d620ae3765a78540be7e0117e534d854812c2> relating to RFC2307bis, which suggests
> 
> it's not quite as black-and-white as refusing the support RFC2307bis,
> but then I don't quite understand what type of query it is that you think
> OpenLDAP doesn't support?  Can you send me a link to a conversation
> about this matter on the openldap-technical mailing list so that I can
> understand it better?

If you examine nisNetgroupTriple in OpenLDAP slapd's nis.schema
you'll see that it is not queryable.  This is also why you can't
use an OpenLDAP server as-is to support LDAP netgroups on Solaris.
For testing purposes I use the folowing with OpenLDAP:

       attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
	   DESC 'Netgroup triple'
	   EQUALITY caseIgnoreIA5Match
	   SUBSTR caseIgnoreIA5SubstringsMatch
	   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

This is not a problem with Sun/Mozilla derived LDAP servers (or the
Tivoli server).  I can't find the mailing list message any more
where Howard Chu says they have no intent to support that.

> Currently DBIS supports getnetgrent() and innetgr() calls for netgroups,
> which allow you to enumerate all netgroups (recursively if you like) or
> to test whether a user is a member of a specific netgroup.  Are you saying
> you'd need a function you could use that returns the full list of netgroups
> that a given user is a member of?

That is exactly what I am saying.

> Netservices are structured similarly, having getnetsvent() and
> innetsv() calls which are similar to the netgroup cousins.  Netservices
> don't really simplify the APIs or the LDAP operations needed at the
> back-end, but do provide a better structure for the information in
> the LDAP directory itself.

Part of the reason netgroups in sudo are so slow is that large
enterprises have so many of them and they are global in scope.  So
just having sudo-specific netgroups would probably help.

> I am also considering adding support for LDAP persistent search in
> DBIS.  This would allow subscribers, such as sudo (and autofs) to
> do one of two things.  Either you could call in as frequently as
> you liked and always get the most up-to-date data (the complete set
> or just a delta of changes), or you could have a thread constantly
> pick-up new changes to your map the moment they happen and never
> have to worry about TTLs again.

Since sudo is not really a persistent process I don't think that
persistent search is much of an issue for it.

 - todd