[sudo-workers] Add support for DBIS netservices
Mark.Bannister at morganstanley.com
Tue Aug 25 01:09:34 MDT 2015
> 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.
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.
More information about the sudo-workers