[sudo-workers] Add support for DBIS netservices

[Bannister, Mark]

> > 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.



Well the DBIS layer will handle the recursion for you so it will be simpler anyway.

Also, as you suspected later on in the email, netservices groups roles & permissioning

by application, so there will be a sudo tree under which all the sudo permissions

can be found.



> > 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.



Besides listing which netgroups a user is a member of (I'll add that for sure

now I know it will be useful), what other lookups do you do that are not

simple name/value lookups?



> > 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.



In draft-bannister-dbis-netgroup-05 I have:



       attributetype ( 1.3.6.1.4.1.23780.219.2.37 NAME 'netgroupTriple'

         DESC 'Case exact netgroup triple'

         EQUALITY caseExactMatch

         SUBSTR caseExactSubstringsMatch

         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )



So that is already fixing your searchability problem (you'll also notice I fixed the case

sensitivity issue inherent in RFC2307 & RFC2307bis).  This attribute is actually, believe

it or not, for backwards compatibility.  Moving forwards I've recommended separating

user and host portions of the triple into different attributes which make it easier to

search:



       attributetype ( 1.3.6.1.4.1.23780.219.2.8 NAME 'netgroupHost'

         DESC 'Host or domain that is assigned to a netgroup'

         EQUALITY caseIgnoreIA5Match

         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )



       attributetype ( 1.3.6.1.4.1.23780.219.2.9 NAME 'netgroupUser'

         DESC 'User who is assigned to a netgroup'

         EQUALITY caseExactMatch

         SUBSTR caseExactSubstringsMatch

         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )



> > 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.



So I'll add it to the DBIS API.  I'm already handling recursion, so it's pretty trivial to do.



> > 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.



Example netservices I have given in the drafts are ssh:login, ftp:login and

web:login/anonymous.  However I very much designed this with sudo in mind,

so you would have netservices named, for example, sudo:root/ALL or

sudo:myapp/cluster/restart or however we decide is the best way to organise

the hierarchy, the main point being that there is a hierarchy dedicated to sudo,

and all sudo needs to do is either test to see if a particular user has been granted

a specific netservice, or to enumerate a list of all netservices granted to a particular

user.



> > 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.



Ok, that's good to know this use-case fits autofs well but is not needed

by sudo.



Mark.



p.s. I'm talking on the subject of DBIS at LDAPCon 2015<http://ldapcon.org/2015/?page_id=76> in Edinburgh this November

if you or anyone is interested in coming along.




________________________________

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies; do not disclose, use or act upon the information; and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.