-Design Features
-===============
-
- * Sudo no longer needs to read sudoers in its entirety. Parsing of
- /etc/sudoers requires the entire file to be read. The LDAP feature of sudo
- uses two (sometimes three) LDAP queries per invocation. It never reads all
- the sudoer entries in the LDAP store. This makes it especially fast and
- particularly usable in LDAP environments. The first query is to parse
- default options (see below). The second is to match against the username or
- groups a user belongs to. (The special ALL tag is matched in this query
- too.) If no match is made against the username, the third query pulls the
- entries that match against user netgroups to compare back to the user.
-
- * Sudo no longer blows up if there is a typo. Parsing of /etc/sudoers can
- still blow up when sudo is invoked. However when using the LDAP feature of
- sudo, LDAP syntax rules are applied before the data is uploaded into the
- LDAP server, so proper syntax is always guaranteed! One can of course still
- insert a bogus hostname or username, but sudo will not care.
-
- * Options inside of entries now override global default options.
- /etc/sudoers allowed for only default options and limited options associated
- with user/host/command aliases. The syntax can be difficult for the newbie.
- The LDAP feature attempts to simplify this and yet still provide maximum
- flexibility.
-
- Sudo first looks for an entry called 'cn=default' in the SUDOers container.
- If found, the multi-valued sudoOption attribute is parsed the same way the
- global 'Defaults' line in /etc/sudoers is parsed.
-
- If on the second or third query, a response contains a sudoRole which
- matches against the user, host, and command, then the matched object is
- scanned for a additional options to override the top-level defaults. See
- the example LDAP content below for more information.
-
- * Visudo is no longer needed. Visudo provides locking and syntax checking
- against the /etc/sudoers file. Since LDAP updates are atomic, locking is no
- longer necessary. Because syntax is checked when the data is inserted into
- LDAP, the sudoers syntax check becomes unnecessary.
-
- * Aliases are no longer needed. User, Host, and Command Aliases were setup
- to allow simplification and readability of the sudoers files. Since the
- LDAP sudoer entry allows multiple values for each of its attributes and
- since most LDAP browsers are graphical and easy to work with, original
- aliases are no longer needed.
-
- If you want to specify lots of users into an entry or want to have similar
- entries with identical users, then use either groups or user netgroups.
- Thats what groups and netgroups are for and Sudo handles this well.
- Alternately, one can just paste them all into the LDAP record.
-
- If you want to specify lots of hosts into an entry, use netgroups or IP
- address matches (10.2.3.4/255.255.0.0). Thats what netgroups are for and
- Sudo handles this well. Or just past them all into the LDAP record.
-
- If you want to specify lots of commands, use directories or wildcards, or
- just paste them all into LDAP. That's what it's for.
-
- * The /etc/sudoers file can be disabled. Paranoid security administrators
- can now disallow parsing of any local /etc/sudoers file by an LDAP
- sudoOption 'ignore_local_sudoers'. This way all sudoers can be controlled
- and audited in one place because local entries are not allowed.
- In fact, if this option is included in the cn=defaults object of LDAP,
- sudo won't even look for a /etc/sudoers file.
-
- * The sudo binary compiled with LDAP support should be totally backward
- compatible and be syntactically and source code equivalent to its non
- LDAP-enabled build.
-
-