[sudo-workers] Add support for DBIS netservices

[Bannister, Mark]

> The sudo plugin interface is really intended to allow you to use a

> foreign (i.e. not sudoers) security policy with the sudo front-end.

> The sudoers plugin itself supports an nss-ish interface with file,

> ldap and sssd backends.  What you seems to be proposing sounds

> similar to sssd which also does caching of LDAP results and has its

> own sudoers backend/source.



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



> One of the biggest usability problems with user netgroups and LDAP

> under sudo is you cannot use them in a simple query to return all

> of a user's sudoRole objects as there is no interface to enumerate

> all the netgroups a user is a member of.  In the past, sudo had to

> query all matching sudoRoles with a member that matches "+*" which

> was woefully inefficient (and slow).



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?



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.



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.



> Sudo 1.8.12 and above are capable of querying a user's netgroups

> directly so they can be used in a query but not all LDAP servers

> support such queries.  OpenLDAP in particular refuses to support

> RFC2307bis since it was never standardized.  It looks like netservices

> do support queries that would make it possible to enumberate a

> user's netservices.  Is that correct?



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=14dd620ae3765a78540be7e0117e534d854812c2> 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?



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?



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.



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.

Interested?



Thanks,

Mark.




________________________________

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.