RFC: LDAP schema

[Aaron Spangler]

Request for Comment.  I propose (and am using) the following LDAP schema
extension.  I don't have official oid's yet, so replace X.X with
whatever...

Please, if someone has some recommendations on Syntax or whatever,
please let me know!

attributetype ( 1.3.6.X.X.1.1
    Name 'sudoUser'
    DESC 'User(s) who may run sudo'
    Syntax 1.3.6.1.4.1.1466.115.121.1.26)

attributetype ( 1.3.6.X.X.1.2
    Name 'sudoHost'
    DESC 'Host(s) who may run sudo'
    Syntax 1.3.6.1.4.1.1466.115.121.1.15 )

attributetype ( 1.3.6.X.X.1.3
    Name 'sudoCommand'
    DESC 'Commands(s) to be executed by sudo'
    Syntax 1.3.6.1.4.1.1466.115.121.1.26)

attributetype ( 1.3.6.X.X.1.4
    Name 'sudoOption'
    DESC 'Options(s) followed by sudo'
    Syntax 1.3.6.1.4.1.1466.115.121.1.26 )

objectclass (1.3.6.X.X.2.1 NAME 'sudoRole' SUP top STRUCTURAL
    DESC 'Sudoer Entries'
    MUST ( cn )
    MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoOption $ description )
)


# Make sure you put an index on sudoUser.  None of the other attributes
require an index since only the sudoUser option is searched.

A typical sudo invocation performs either two or three queries.

Query 1:
The first query does a search against 'cn=defaults,ou=SUDOers,...' and
primes the sudo defaults from multiple sudoOption attributes (if any
exist)

Query 2:
The second query does a search against the username and groups the user
belongs to
'(|(sudoUser=<username>)(sudoUser=%<group1>)(sudoUser=%<group2>)(sudoUser=ALL))'

As results come back, the sudoHost attributes are matched.  If any
entries match, they are compared against the sudoCommand (using the
internal sudo matching code).  If everything matches, then the
sudoOption(s) are parsed so that they override the ones from Query1.

Query 3:
If none of the entries returned in Query 2 match with the normal rules,
than a third and final query is performed against any sudoer entries
that contain user netgroups. '(sudoUser=+*)'.  As they entries come
back, they are checked to see if our user belongs to the netgroups.
Plus all the other criteria in step 2. (including option parsing).

So the number of queries against the LDAP server never exceed 3 and the
entire sudoers data store is never parsed in entirety!  The other
advantage is that sudo will never fail due to an improperly formmated
sudoers file.  (This is because LDAP only allows the specific attributes
and objects you specify.  Nothing else can be stored.)

Also you don't have to deal with file locking issues since updates to
LDAP are atomic.  One no longer needs to use the 'visudo' command.  Any
LDAP browser can update the sudo ldap store (provided the administrator
has appropriate write access to the container or tree).  I recommand
ldapBrowser, or GQ or ConsoleOne.  (or even by hand via
/usr/bin/ldapadd).

How do you migrate?  I have written a perl script that takes most
sudoers files and creats an LDIF file that can be imported via 'ldapadd'
or any ldap browser that supports LDIF format.

If the sudoUser begins with '+', it is a user netgroup.  If the sudoUser
begins with '%' it is a group.  If the sudoUser is 'ALL', any user
matches.  All other sudoUser are interpreted as a username.

If the sudoHost begins with a '+', it is a host netgroup.  It is also
checked against IP address matches and may contain wildcards for domain
or IP matching.

Multiple sudoOptions can be specified.


Please reply with comments or suggestions.

 - Aaron