/etc/sudoers.
Using LDAP for _\bs_\bu_\bd_\bo_\be_\br_\bs has several benefits:
+\bo s\bsu\bud\bdo\bo no longer needs to read _\bs_\bu_\bd_\bo_\be_\br_\bs in its entirety.
- Parsing of _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\be_\br_\bs requires the entire file to be
- read. When LDAP is used, there are only two or three
- LDAP queries per invocation. This makes it especially
- fast and particularly usable in LDAP environments.
- The first query is to parse global options (see
- below). The second is to match against the user's
- name and the groups that the user belongs to. (The
- special ALL tag is matched in this query too.) If no
- match is returned for the user's name and groups, a
- third query returns all entries contain user netgroups
- and checks to see if the user belongs to any of them.
+ When LDAP is used, there are only two or three LDAP
+ queries per invocation. This makes it especially fast
+ and particularly usable in LDAP environments.
+\bo s\bsu\bud\bdo\bo no longer exits if there is a typo in _\bs_\bu_\bd_\bo_\be_\br_\bs.
It is not possible to load LDAP data into the server
typos in a user or host name, but this will not pre-
vent s\bsu\bud\bdo\bo from running.
- +\bo Options inside of entries now override global default
- options. _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\be_\br_\bs only supports default options
- and limited options associated with user/host/commands
- and aliases. The syntax is complicated and can be
- difficult for users to understand.
-
- Sudo first looks for an entry called cn=default in the
- SUDOers container. If found, the multi-valued sudoOp-
- tion attribute is parsed the same way the global
- Defaults line in _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\be_\br_\bs 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 that override the top-level
- defaults. See the example LDAP content below for more
- information.
+ +\bo It is possible to specify per-entry options that over-
+ ride the global default options. _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\be_\br_\bs only
+ supports default options and limited options associ-
+ ated with user/host/commands/aliases. The syntax is
+ complicated and can be difficult for users to under-
+ stand. Placing the options directly in the entry is
+ more natural.
+\bo v\bvi\bis\bsu\bud\bdo\bo is no longer needed. v\bvi\bis\bsu\bud\bdo\bo provides locking
and syntax checking of the _\b/_\be_\bt_\bc_\b/_\bs_\bu_\bd_\bo_\be_\br_\bs file. Since
inserted into LDAP, there is no need for a specialized
tool to check syntax.
+ Another major difference between LDAP and file-based _\bs_\bu_\bd_\bo_\b-
+ _\be_\br_\bs is that in LDAP, s\bsu\bud\bdo\bo-specific Aliases are not sup-
+ ported.
+ For the most part, there is really no need for s\bsu\bud\bdo\bo-spe-
+ cific Aliases. Unix groups or user netgroups can be used
+ in place of User_Aliases and RunasAliases. Host netgroups
+ can be used in place of HostAliases. Since Unix groups
+ and netgroups can also be stored in LDAP there is no real
+ need for s\bsu\bud\bdo\bo-specific aliases.
+
+ Cmnd_Aliases are not really required either since it is
+ possible to have multiple users listed in a sudoRole.
+ Instead of defining a Cmnd_Alias that is referenced by
+ multiple users, one can create a sudoRole that contains
+ the commands and assign multiple users to it.
-1.7 January 20, 2008 1
+1.7 January 20, 2008 1
-SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
- +\bo Aliases are no longer needed. User, Host, and Cmnd
- Aliases were designed to simplify organization of
- _\bs_\bu_\bd_\bo_\be_\br_\bs files and to improve readability. Since an
- LDAP _\bs_\bu_\bd_\bo_\be_\br_\bs entry allows multiple values for each of
- its attributes, and since most LDAP browsers are
- graphical and easy to work with, these aliases are no
- longer needed.
- If you wish to specify a large number of users into an
- entry or wish to have similar entries with identical
- users, then either use groups or user netgroups.
- Alternately, they can all just be pasted into the LDAP
- record.
+SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
- If you need to specify a large number of hosts in an
- entry, use netgroups or IP address matches
- (10.2.3.4/255.255.0.0). Alternately, they can all
- just be pasted into the LDAP record.
S\bSU\bUD\bDO\bOe\ber\brs\bs L\bLD\bDA\bAP\bP c\bco\bon\bnt\bta\bai\bin\bne\ber\br
The equivalent of a sudoer in LDAP is a sudoRole. It con-
sists of the following components:
- sudoUser
+ s\bsu\bud\bdo\boU\bUs\bse\ber\br
A user name, uid (prefixed with '#'), Unix group (pre-
fixed with a '%') or user netgroup (prefixed with a
'+').
- sudoHost
+ s\bsu\bud\bdo\boH\bHo\bos\bst\bt
A host name, IP address, IP network, or host netgroup
(prefixed with a '+'). The special value ALL will
match any host.
- sudoCommand
+ s\bsu\bud\bdo\boC\bCo\bom\bmm\bma\ban\bnd\bd
A Unix command with optional command line arguments,
potentially including globbing characters (aka wild
+ cards). The special value ALL will match any command.
+ If a command is prefixed with an exclamation point
+ '!', the user will be prohibited from running that
+ command.
+ s\bsu\bud\bdo\boO\bOp\bpt\bti\bio\bon\bn
+ Identical in function to the global options described
+ above, but specific to the sudoRole in which it
+ resides.
+ s\bsu\bud\bdo\boR\bRu\bun\bnA\bAs\bsU\bUs\bse\ber\br
+ A user name or uid (prefixed with '#') that commands
+ may be run as or a Unix group (prefixed with a '%') or
+ user netgroup (prefixed with a '+') that contains a
+ list of users that commands may be run as. The spe-
+ cial value ALL will match any user.
-1.7 January 20, 2008 2
+ s\bsu\bud\bdo\boR\bRu\bun\bnA\bAs\bsG\bGr\bro\bou\bup\bp
+ A Unix group or gid (prefixed with '#') that commands
+1.7 January 20, 2008 2
-SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
- cards). The special value ALL will match any command.
- sudoOption
- Similar to the global options described above, but
- specific to the sudoRole in which it resides.
+SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
- sudoRunAsUser
- A user name or uid (prefixed with '#') that commands
- may be run as or a Unix group (prefixed with a '%') or
- user netgroup (prefixed with a '+') that contains a
- list of users that commands may be run as. The spe-
- cial value ALL will match any user.
- sudoRunAsGroup
- A Unix group or gid (prefixed with '#') that commands
may be run as. The special value ALL will match any
group.
- Each entry listed above contains a single value, but may
- be repeated multiple times. A sudoRole must contain at
- least one sudoUser, sudoHost and sudoCommand.
+ Each component listed above should contain a single value,
+ but there may be multiple instances of each component
+ type. A sudoRole must contain at least one sudoUser,
+ sudoHost and sudoCommand.
The following example allows users in group wheel to run
any command on any host via s\bsu\bud\bdo\bo:
sudoHost: ALL
sudoCommand: ALL
+ A\bAn\bna\bat\bto\bom\bmy\by o\bof\bf L\bLD\bDA\bAP\bP s\bsu\bud\bdo\boe\ber\brs\bs l\blo\boo\bok\bku\bup\bp
+
+ When looking up a sudoer using LDAP there are only two or
+ three LDAP queries per invocation. The first query is to
+ parse the global options. The second is to match against
+ the user's name and the groups that the user belongs to.
+ (The special ALL tag is matched in this query too.) If no
+ match is returned for the user's name and groups, a third
+ query returns all entries containing user netgroups and
+ checks to see if the user belongs to any of them.
+
D\bDi\bif\bff\bfe\ber\bre\ben\bnc\bce\bes\bs b\bbe\bet\btw\bwe\bee\ben\bn L\bLD\bDA\bAP\bP a\ban\bnd\bd n\bno\bon\bn-\b-L\bLD\bDA\bAP\bP s\bsu\bud\bdo\boe\ber\brs\bs
There are some subtle differences in the way sudoers is
handled once in LDAP. Probably the biggest is that
- according to the RFC, LDAP's ordering is arbitrary and you
+ according to the RFC, LDAP ordering is arbitrary and you
cannot expect that Attributes and Entries are returned in
- any order. If there are conflicting command rules on an
- entry, the negative takes precedence. This is called
- paranoid behavior (not necessarily the most specific
- match).
+ any specific order. If there are conflicting command
+ rules on an entry, the negative takes precedence. This is
+ called paranoid behavior (not necessarily the most spe-
+ cific match).
Here is an example:
+
+
+
1.7 January 20, 2008 3
SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
- # LDAP equivalent of Johnny
+ # LDAP equivalent of johnny
# Allows all commands except shell
dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
objectClass: sudoRole
sudoCommand: ALL
sudoCommand: !/bin/sh
- # LDAP equivalent of Puddles
+ # LDAP equivalent of puddles
# Notice that even though ALL comes last, it still behaves like
# role1 since the LDAP code assumes the more paranoid configuration
dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
Another difference is that negations on the Host, User or
Runas are currently ignorred. For example, the following
- attributes do not do what they might appear to do.
+ attributes do not behave the way one might expect.
# does not match all but joe
# rather, does not match anyone
options are listed below in upper case but are parsed in a
case-independent manner.
- URI ldap[s]://[hostname[:port]] ...
+ U\bUR\bRI\bI ldap[s]://[hostname[:port]] ...
Specifies a whitespace-delimited list of one or more
URIs describing the LDAP server(s) to connect to. The
_\bp_\br_\bo_\bt_\bo_\bc_\bo_\bl may be either l\bld\bda\bap\bp or l\bld\bda\bap\bps\bs, the latter being
libraries used on most commercial versions of Unix are
only capable of supporting one or the other.
- HOST name[:port] ...
+ H\bHO\bOS\bST\bT name[:port] ...
If no U\bUR\bRI\bI is specified, the H\bHO\bOS\bST\bT parameter specifies a
whitespace-delimited list of LDAP servers to connect
to. Each host may include an optional _\bp_\bo_\br_\bt separated
favor of the U\bUR\bRI\bI specification and is included for
backwards compatibility.
- PORT port_number
+ P\bPO\bOR\bRT\bT port_number
If no U\bUR\bRI\bI is specified, the P\bPO\bOR\bRT\bT parameter specifies
the default port to connect to on the LDAP server if a
H\bHO\bOS\bST\bT parameter does not specify the port itself. If
parameter is deprecated in favor of the U\bUR\bRI\bI specifica-
tion and is included for backwards compatibility.
- BIND_TIMELIMIT seconds
+ B\bBI\bIN\bND\bD_\b_T\bTI\bIM\bME\bEL\bLI\bIM\bMI\bIT\bT seconds
The B\bBI\bIN\bND\bD_\b_T\bTI\bIM\bME\bEL\bLI\bIM\bMI\bIT\bT parameter specifies the amount of
time, in seconds, to wait while trying to connect to
an LDAP server. If multiple U\bUR\bRI\bIs or H\bHO\bOS\bST\bTs are speci-
SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
- TIMELIMIT seconds
+ T\bTI\bIM\bME\bEL\bLI\bIM\bMI\bIT\bT seconds
The T\bTI\bIM\bME\bEL\bLI\bIM\bMI\bIT\bT parameter specifies the amount of time,
in seconds, to wait for a response to an LDAP query.
- SUDOERS_BASE base
+ S\bSU\bUD\bDO\bOE\bER\bRS\bS_\b_B\bBA\bAS\bSE\bE base
The base DN to use when performing s\bsu\bud\bdo\bo LDAP queries.
Typically this is of the form ou=SUDOers,dc=exam-
ple,dc=com for the domain example.com.
- SUDOERS_DEBUG debug_level
+ S\bSU\bUD\bDO\bOE\bER\bRS\bS_\b_D\bDE\bEB\bBU\bUG\bG debug_level
This sets the debug level for s\bsu\bud\bdo\bo LDAP queries.
Debugging information is printed to the standard
error. A value of 1 results in a moderate amount of
be set in a production environment as the extra infor-
mation is likely to confuse users.
- BINDDN DN
+ B\bBI\bIN\bND\bDD\bDN\bN DN
The B\bBI\bIN\bND\bDD\bDN\bN parameter specifies the identity, in the
form of a Distinguished Name (DN), to use when per-
forming LDAP operations. If not specified, LDAP oper-
default, most LDAP servers will allow anonymous
access.
- BINDPW secret
+ B\bBI\bIN\bND\bDP\bPW\bW secret
The B\bBI\bIN\bND\bDP\bPW\bW parameter specifies the password to use
when performing LDAP operations. This is typically
used in conjunction with the B\bBI\bIN\bND\bDD\bDN\bN parameter.
- ROOTBINDDN DN
+ R\bRO\bOO\bOT\bTB\bBI\bIN\bND\bDD\bDN\bN DN
The R\bRO\bOO\bOT\bTB\bBI\bIN\bND\bDD\bDN\bN parameter specifies the identity, in
the form of a Distinguished Name (DN), to use when
performing privileged LDAP operations, such as _\bs_\bu_\bd_\bo_\be_\br_\bs
should be stored in _\b/_\be_\bt_\bc_\b/_\bl_\bd_\ba_\bp_\b._\bs_\be_\bc_\br_\be_\bt. If not speci-
fied, the B\bBI\bIN\bND\bDD\bDN\bN identity is used (if any).
- LDAP_VERSION number
+ L\bLD\bDA\bAP\bP_\b_V\bVE\bER\bRS\bSI\bIO\bON\bN number
The version of the LDAP protocol to use when connect-
ing to the server. The default value is protocol ver-
sion 3.
- SSL on/true/yes/off/false/no
+ S\bSS\bSL\bL on/true/yes/off/false/no
If the S\bSS\bSL\bL parameter is set to on, true or yes, TLS
(SSL) encryption is always used when communicating
with the LDAP server. Typically, this involves con-
necting to the server on port 636 (ldaps).
- SSL start_tls
+ S\bSS\bSL\bL start_tls
If the S\bSS\bSL\bL parameter is set to start_tls, the LDAP
server connection is initiated normally and TLS
encryption is begun before the bind credentials are
ter is only supported by LDAP servers that honor the
start_tls extension, such as the OpenLDAP server.
- TLS_CHECKPEER on/true/yes/off/false/no
+ T\bTL\bLS\bS_\b_C\bCH\bHE\bEC\bCK\bKP\bPE\bEE\bER\bR on/true/yes/off/false/no
If enabled, T\bTL\bLS\bS_\b_C\bCH\bHE\bEC\bCK\bKP\bPE\bEE\bER\bR will cause the LDAP server's
TLS certificated to be verified. If the server's TLS
certificate cannot be verified (usually because it is
be unable to connect to it. If T\bTL\bLS\bS_\b_C\bCH\bHE\bEC\bCK\bKP\bPE\bEE\bER\bR is dis-
abled, no check is made.
- TLS_CACERTFILE file name
+ T\bTL\bLS\bS_\b_C\bCA\bAC\bCE\bER\bRT\bTF\bFI\bIL\bLE\bE file name
The path to a certificate authority bundle which con-
tains the certificates for all the Certificate Author-
ities the client knows to be valid, e.g.
_\b/_\be_\bt_\bc_\b/_\bs_\bs_\bl_\b/_\bc_\ba_\b-_\bb_\bu_\bn_\bd_\bl_\be_\b._\bp_\be_\bm. This option is only supported
by the OpenLDAP libraries.
- TLS_CACERTDIR directory
+ T\bTL\bLS\bS_\b_C\bCA\bAC\bCE\bER\bRT\bTD\bDI\bIR\bR directory
Similar to T\bTL\bLS\bS_\b_C\bCA\bAC\bCE\bER\bRT\bTF\bFI\bIL\bLE\bE but instead of a file, it is
a directory containing individual Certificate Author-
ity certificates, e.g. _\b/_\be_\bt_\bc_\b/_\bs_\bs_\bl_\b/_\bc_\be_\br_\bt_\bs. The directory
E\bER\bRT\bTF\bFI\bIL\bLE\bE. This option is only supported by the OpenL-
DAP libraries.
- TLS_CERT file name
+ T\bTL\bLS\bS_\b_C\bCE\bER\bRT\bT file name
The path to a file containing the client certificate
which can be used to authenticate the client to the
- LDAP server.
+ LDAP server. The certificate type depends on the LDAP
+ libraries used.
- OpenLDAP tls_cert /etc/ssl/client_cert.pem
+ OpenLDAP:
+ tls_cert /etc/ssl/client_cert.pem
- Netscape-derived tls_cert /var/ldap/cert7.db
+ Netscape-derived:
+ tls_cert /var/ldap/cert7.db
When using Netscape-derived libraries, this file may
also contain Certificate Authority certificates.
- TLS_KEY file name
+ T\bTL\bLS\bS_\b_K\bKE\bEY\bY file name
The path to a file containing the private key which
matches the certificate specified by T\bTL\bLS\bS_\b_C\bCE\bER\bRT\bT. The
- private key must not be password-protected.
+ private key must not be password-protected. The key
+ type depends on the LDAP libraries used.
- OpenLDAP tls_cert /etc/ssl/client_key.pem
+ OpenLDAP:
+ tls_cert /etc/ssl/client_key.pem
- Netscape-derived tls_cert /var/ldap/key3.db
-
- TLS_RANDFILE file name
- The T\bTL\bLS\bS_\b_R\bRA\bAN\bND\bDF\bFI\bIL\bLE\bE parameter specifies the path to an
- entropy source for systems that lack a random device.
- It is generally used in conjunction with _\bp_\br_\bn_\bg_\bd or _\be_\bg_\bd.
- This option is only supported by the OpenLDAP
+ Netscape-derived:
+ tls_cert /var/ldap/key3.db
SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
+ T\bTL\bLS\bS_\b_R\bRA\bAN\bND\bDF\bFI\bIL\bLE\bE file name
+ The T\bTL\bLS\bS_\b_R\bRA\bAN\bND\bDF\bFI\bIL\bLE\bE parameter specifies the path to an
+ entropy source for systems that lack a random device.
+ It is generally used in conjunction with _\bp_\br_\bn_\bg_\bd or _\be_\bg_\bd.
+ This option is only supported by the OpenLDAP
libraries.
- TLS_CIPHERS cipher list
+ T\bTL\bLS\bS_\b_C\bCI\bIP\bPH\bHE\bER\bRS\bS cipher list
The T\bTL\bLS\bS_\b_C\bCI\bIP\bPH\bHE\bER\bRS\bS parameter allows the administer to
restrict which encryption algorithms may be used for
TLS (SSL) connections. See the OpenSSL manual for a
list of valid ciphers. This option is only supported
by the OpenLDAP libraries.
- USE_SASL on/true/yes/off/false/no
+ U\bUS\bSE\bE_\b_S\bSA\bAS\bSL\bL on/true/yes/off/false/no
Enable U\bUS\bSE\bE_\b_S\bSA\bAS\bSL\bL for LDAP servers that support SASL
authentication.
- SASL_AUTH_ID identity
+ S\bSA\bAS\bSL\bL_\b_A\bAU\bUT\bTH\bH_\b_I\bID\bD identity
The SASL user name to use when connecting to the LDAP
server. By default, s\bsu\bud\bdo\bo will use an anonymous con-
nection.
- ROOTUSE_SASL on/true/yes/off/false/no
+ R\bRO\bOO\bOT\bTU\bUS\bSE\bE_\b_S\bSA\bAS\bSL\bL on/true/yes/off/false/no
Enable R\bRO\bOO\bOT\bTU\bUS\bSE\bE_\b_S\bSA\bAS\bSL\bL to enable SASL authentication when
connecting to an LDAP server from a privileged pro-
cess, such as s\bsu\bud\bdo\bo.
- ROOTSASL_AUTH_ID identity
+ R\bRO\bOO\bOT\bTS\bSA\bAS\bSL\bL_\b_A\bAU\bUT\bTH\bH_\b_I\bID\bD identity
The SASL user name to use when R\bRO\bOO\bOT\bTU\bUS\bSE\bE_\b_S\bSA\bAS\bSL\bL is
enabled.
- SASL_SECPROPS none/properties
+ S\bSA\bAS\bSL\bL_\b_S\bSE\bEC\bCP\bPR\bRO\bOP\bPS\bS none/properties
SASL security properties or _\bn_\bo_\bn_\be for no properties.
See the SASL programmer's manual for details.
- KRB5_CCNAME file name
+ K\bKR\bRB\bB5\b5_\b_C\bCC\bCN\bNA\bAM\bME\bE file name
The path to the Kerberos 5 credential cache to use
when authenticating with the remote server.
The following sources are recognized:
- files read sudoers from a file (usually F</etc/sudoers>)
- ldap read sudoers from LDAP
- In addition, the entry [NOTFOUND=return] will short-cir-
- cuit the search if the user was not found in the preceding
- source.
SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
+ files read sudoers from F</etc/sudoers>
+ ldap read sudoers from LDAP
+
+ In addition, the entry [NOTFOUND=return] will short-cir-
+ cuit the search if the user was not found in the preceding
+ source.
+
To consult LDAP first followed by the local sudoers file
(if it exists), use:
-
-
-
-
-
-
-
S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- _\bl_\bd_\ba_\bp_\b._\bc_\bo_\bn_\bf(4), _\bs_\bu_\bd_\bo_\be_\br_\bs(4)
+ _\bl_\bd_\ba_\bp_\b._\bc_\bo_\bn_\bf(4), _\bs_\bu_\bd_\bo_\be_\br_\bs(5)
C\bCA\bAV\bVE\bEA\bAT\bTS\bS
- parsing differences between LDAP and file sudoers
+ The way that _\bs_\bu_\bd_\bo_\be_\br_\bs is parsed differs between Note that
+ there are differences in the way that LDAP-based _\bs_\bu_\bd_\bo_\be_\br_\bs
+ is parsed compared to file-based _\bs_\bu_\bd_\bo_\be_\br_\bs. See the "Dif-
+ ferences between LDAP and non-LDAP sudoers" section for
+ more information.
B\bBU\bUG\bGS\bS
If you feel you have found a bug in s\bsu\bud\bdo\bo, please submit a
-
-
-
-
.PP
Using \s-1LDAP\s0 for \fIsudoers\fR has several benefits:
.IP "\(bu" 4
-\&\fBsudo\fR no longer needs to read \fIsudoers\fR in its entirety. Parsing
-of \fI/etc/sudoers\fR requires the entire file to be read. When \s-1LDAP\s0
-is used, there are only two or three \s-1LDAP\s0 queries per invocation.
+\&\fBsudo\fR no longer needs to read \fIsudoers\fR in its entirety. When
+\&\s-1LDAP\s0 is used, there are only two or three \s-1LDAP\s0 queries per invocation.
This makes it especially fast and particularly usable in \s-1LDAP\s0
-environments. The first query is to parse global options (see
-below). The second is to match against the user's name and the
-groups that the user belongs to. (The special \s-1ALL\s0 tag is matched
-in this query too.) If no match is returned for the user's name
-and groups, a third query returns all entries contain user netgroups
-and checks to see if the user belongs to any of them.
+environments.
.IP "\(bu" 4
\&\fBsudo\fR no longer exits if there is a typo in \fIsudoers\fR.
It is not possible to load \s-1LDAP\s0 data into the server that does
It is still possible to have typos in a user or host name, but
this will not prevent \fBsudo\fR from running.
.IP "\(bu" 4
-Options inside of entries now override global default options.
-\&\fI/etc/sudoers\fR only supports default options and limited options
-associated with user/host/commands and aliases. The syntax is
-complicated and can be difficult for users to understand.
-.Sp
-Sudo first looks for an entry called \f(CW\*(C`cn=default\*(C'\fR in the \f(CW\*(C`SUDOers\*(C'\fR
-container. If found, the multi-valued \f(CW\*(C`sudoOption\*(C'\fR attribute is
-parsed the same way the global \f(CW\*(C`Defaults\*(C'\fR line in \fI/etc/sudoers\fR
-is parsed.
-.Sp
-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 that override the top-level
-defaults. See the example \s-1LDAP\s0 content below for more information.
+It is possible to specify per-entry options that override the global
+default options. \fI@sysconfdir@/sudoers\fR only supports default options and
+limited options associated with user/host/commands/aliases. The
+syntax is complicated and can be difficult for users to understand.
+Placing the options directly in the entry is more natural.
.IP "\(bu" 4
\&\fBvisudo\fR is no longer needed. \fBvisudo\fR provides locking and
-syntax checking of the \fI/etc/sudoers\fR file. Since \s-1LDAP\s0 updates
+syntax checking of the \fI@sysconfdir@/sudoers\fR file. Since \s-1LDAP\s0 updates
are atomic, locking is no longer necessary. Because syntax is
checked when the data is inserted into \s-1LDAP\s0, there is no need
for a specialized tool to check syntax.
-.IP "\(bu" 4
-Aliases are no longer needed. User, Host, and Cmnd Aliases were
-designed to simplify organization of \fIsudoers\fR files and to
-improve readability. Since an \s-1LDAP\s0 \fIsudoers\fR entry allows multiple
-values for each of its attributes, and since most \s-1LDAP\s0 browsers are
-graphical and easy to work with, these aliases are no longer
-needed.
-.Sp
-If you wish to specify a large number of users into an entry or
-wish to have similar entries with identical users, then either use
-groups or user netgroups. Alternately, they can all just be pasted
-into the \s-1LDAP\s0 record.
-.Sp
-If you need to specify a large number of hosts in an entry, use
-netgroups or \s-1IP\s0 address matches (10.2.3.4/255.255.0.0). Alternately,
-they can all just be pasted into the \s-1LDAP\s0 record.
+.PP
+Another major difference between \s-1LDAP\s0 and file-based \fIsudoers\fR
+is that in \s-1LDAP\s0, \fBsudo\fR\-specific Aliases are not supported.
+.PP
+For the most part, there is really no need for \fBsudo\fR\-specific
+Aliases. Unix groups or user netgroups can be used in place of
+User_Aliases and RunasAliases. Host netgroups can be used in place
+of HostAliases. Since Unix groups and netgroups can also be stored
+in \s-1LDAP\s0 there is no real need for \fBsudo\fR\-specific aliases.
+.PP
+Cmnd_Aliases are not really required either since it is possible
+to have multiple users listed in a sudoRole. Instead of defining
+a Cmnd_Alias that is referenced by multiple users, one can create
+a sudoRole that contains the commands and assign multiple users
+to it.
.Sh "SUDOers \s-1LDAP\s0 container"
.IX Subsection "SUDOers LDAP container"
The \fIsudoers\fR configuration is contained in the \f(CW\*(C`ou=SUDOers\*(C'\fR \s-1LDAP\s0
.PP
Sudo first looks for the \f(CW\*(C`cn=default\*(C'\fR entry in the SUDOers container.
If found, the multi-valued \f(CW\*(C`sudoOption\*(C'\fR attribute is parsed in the
-same manner as a global \f(CW\*(C`Defaults\*(C'\fR line in \fI/etc/sudoers\fR. In
+same manner as a global \f(CW\*(C`Defaults\*(C'\fR line in \fI@sysconfdir@/sudoers\fR. In
the following example, the \f(CW\*(C`SSH_AUTH_SOCK\*(C'\fR variable will be preserved
in the environment for all users.
.PP
.PP
The equivalent of a sudoer in \s-1LDAP\s0 is a \f(CW\*(C`sudoRole\*(C'\fR. It consists of
the following components:
-.IP "sudoUser" 4
+.IP "\fBsudoUser\fR" 4
.IX Item "sudoUser"
A user name, uid (prefixed with \f(CW'#'\fR), Unix group (prefixed with
a \f(CW'%'\fR) or user netgroup (prefixed with a \f(CW'+'\fR).
-.IP "sudoHost" 4
+.IP "\fBsudoHost\fR" 4
.IX Item "sudoHost"
A host name, \s-1IP\s0 address, \s-1IP\s0 network, or host netgroup (prefixed
with a \f(CW'+'\fR).
The special value \f(CW\*(C`ALL\*(C'\fR will match any host.
-.IP "sudoCommand" 4
+.IP "\fBsudoCommand\fR" 4
.IX Item "sudoCommand"
A Unix command with optional command line arguments, potentially
including globbing characters (aka wild cards).
The special value \f(CW\*(C`ALL\*(C'\fR will match any command.
-.IP "sudoOption" 4
+If a command is prefixed with an exclamation point \f(CW'!'\fR, the
+user will be prohibited from running that command.
+.IP "\fBsudoOption\fR" 4
.IX Item "sudoOption"
-Similar to the global options described above, but specific to the
-\&\f(CW\*(C`sudoRole\*(C'\fR in which it resides.
-.IP "sudoRunAsUser" 4
+Identical in function to the global options described above, but
+specific to the \f(CW\*(C`sudoRole\*(C'\fR in which it resides.
+.IP "\fBsudoRunAsUser\fR" 4
.IX Item "sudoRunAsUser"
A user name or uid (prefixed with \f(CW'#'\fR) that commands may be run
as or a Unix group (prefixed with a \f(CW'%'\fR) or user netgroup (prefixed
with a \f(CW'+'\fR) that contains a list of users that commands may be
run as.
The special value \f(CW\*(C`ALL\*(C'\fR will match any user.
-.IP "sudoRunAsGroup" 4
+.IP "\fBsudoRunAsGroup\fR" 4
.IX Item "sudoRunAsGroup"
A Unix group or gid (prefixed with \f(CW'#'\fR) that commands may be run as.
The special value \f(CW\*(C`ALL\*(C'\fR will match any group.
.PP
-Each entry listed above contains a single value, but may be repeated
-multiple times. A sudoRole must contain at least one \f(CW\*(C`sudoUser\*(C'\fR,
-\&\f(CW\*(C`sudoHost\*(C'\fR and \f(CW\*(C`sudoCommand\*(C'\fR.
+Each component listed above should contain a single value, but there
+may be multiple instances of each component type. A sudoRole must
+contain at least one \f(CW\*(C`sudoUser\*(C'\fR, \f(CW\*(C`sudoHost\*(C'\fR and \f(CW\*(C`sudoCommand\*(C'\fR.
.PP
The following example allows users in group wheel to run any command
on any host via \fBsudo\fR:
\& sudoHost: ALL
\& sudoCommand: ALL
.Ve
+.Sh "Anatomy of \s-1LDAP\s0 sudoers lookup"
+.IX Subsection "Anatomy of LDAP sudoers lookup"
+When looking up a sudoer using \s-1LDAP\s0 there are only two or three
+\&\s-1LDAP\s0 queries per invocation. The first query is to parse the global
+options. The second is to match against the user's name and the
+groups that the user belongs to. (The special \s-1ALL\s0 tag is matched
+in this query too.) If no match is returned for the user's name
+and groups, a third query returns all entries containing user
+netgroups and checks to see if the user belongs to any of them.
.Sh "Differences between \s-1LDAP\s0 and non-LDAP sudoers"
.IX Subsection "Differences between LDAP and non-LDAP sudoers"
There are some subtle differences in the way sudoers is handled
once in \s-1LDAP\s0. Probably the biggest is that according to the \s-1RFC\s0,
-\&\s-1LDAP\s0's ordering is arbitrary and you cannot expect that Attributes
-and Entries are returned in any order. If there are conflicting
-command rules on an entry, the negative takes precedence. This is
-called paranoid behavior (not necessarily the most specific match).
+\&\s-1LDAP\s0 ordering is arbitrary and you cannot expect that Attributes
+and Entries are returned in any specific order. If there are
+conflicting command rules on an entry, the negative takes precedence.
+This is called paranoid behavior (not necessarily the most specific
+match).
.PP
Here is an example:
.PP
.Ve
.PP
.Vb 10
-\& # LDAP equivalent of Johnny
+\& # LDAP equivalent of johnny
\& # Allows all commands except shell
\& dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
\& objectClass: sudoRole
.Ve
.PP
.Vb 11
-\& # LDAP equivalent of Puddles
+\& # LDAP equivalent of puddles
\& # Notice that even though ALL comes last, it still behaves like
\& # role1 since the LDAP code assumes the more paranoid configuration
\& dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
.PP
Another difference is that negations on the Host, User or Runas are
currently ignorred. For example, the following attributes do not
-do what they might appear to do.
+behave the way one might expect.
.PP
.Vb 3
\& # does not match all but joe
Only those options explicitly listed in \fI@ldap_conf@\fR that are
supported by \fBsudo\fR are honored. Configuration options are listed
below in upper case but are parsed in a case-independent manner.
-.IP "\s-1URI\s0 ldap[s]://[hostname[:port]] ..." 4
+.IP "\fB\s-1URI\s0\fR ldap[s]://[hostname[:port]] ..." 4
.IX Item "URI ldap[s]://[hostname[:port]] ..."
Specifies a whitespace-delimited list of one or more URIs describing
the \s-1LDAP\s0 server(s) to connect to. The \fIprotocol\fR may be either \fBldap\fR
libraries support the mixing of \f(CW\*(C`ldap://\*(C'\fR and \f(CW\*(C`ldaps://\*(C'\fR URIs.
The Netscape-derived libraries used on most commercial versions of
Unix are only capable of supporting one or the other.
-.IP "\s-1HOST\s0 name[:port] ..." 4
+.IP "\fB\s-1HOST\s0\fR name[:port] ..." 4
.IX Item "HOST name[:port] ..."
If no \fB\s-1URI\s0\fR is specified, the \fB\s-1HOST\s0\fR parameter specifies a
whitespace-delimited list of \s-1LDAP\s0 servers to connect to. Each host
may include an optional \fIport\fR separated by a colon (':'). The
\&\fB\s-1HOST\s0\fR parameter is deprecated in favor of the \fB\s-1URI\s0\fR specification
and is included for backwards compatibility.
-.IP "\s-1PORT\s0 port_number" 4
+.IP "\fB\s-1PORT\s0\fR port_number" 4
.IX Item "PORT port_number"
If no \fB\s-1URI\s0\fR is specified, the \fB\s-1PORT\s0\fR parameter specifies the
default port to connect to on the \s-1LDAP\s0 server if a \fB\s-1HOST\s0\fR parameter
the default is port 389 for \s-1LDAP\s0 and port 636 for \s-1LDAP\s0 over \s-1TLS\s0
(\s-1SSL\s0). The \fB\s-1PORT\s0\fR parameter is deprecated in favor of the \fB\s-1URI\s0\fR
specification and is included for backwards compatibility.
-.IP "\s-1BIND_TIMELIMIT\s0 seconds" 4
+.IP "\fB\s-1BIND_TIMELIMIT\s0\fR seconds" 4
.IX Item "BIND_TIMELIMIT seconds"
The \fB\s-1BIND_TIMELIMIT\s0\fR parameter specifies the amount of time, in seconds,
to wait while trying to connect to an \s-1LDAP\s0 server. If multiple \fB\s-1URI\s0\fRs or
\&\fB\s-1HOST\s0\fRs are specified, this is the amount of time to wait before trying
the next one in the list.
-.IP "\s-1TIMELIMIT\s0 seconds" 4
+.IP "\fB\s-1TIMELIMIT\s0\fR seconds" 4
.IX Item "TIMELIMIT seconds"
The \fB\s-1TIMELIMIT\s0\fR parameter specifies the amount of time, in seconds,
to wait for a response to an \s-1LDAP\s0 query.
-.IP "\s-1SUDOERS_BASE\s0 base" 4
+.IP "\fB\s-1SUDOERS_BASE\s0\fR base" 4
.IX Item "SUDOERS_BASE base"
The base \s-1DN\s0 to use when performing \fBsudo\fR \s-1LDAP\s0 queries. Typically
this is of the form \f(CW\*(C`ou=SUDOers,dc=example,dc=com\*(C'\fR for the domain
\&\f(CW\*(C`example.com\*(C'\fR.
-.IP "\s-1SUDOERS_DEBUG\s0 debug_level" 4
+.IP "\fB\s-1SUDOERS_DEBUG\s0\fR debug_level" 4
.IX Item "SUDOERS_DEBUG debug_level"
This sets the debug level for \fBsudo\fR \s-1LDAP\s0 queries. Debugging
information is printed to the standard error. A value of 1 results
the results of the matches themselves. This parameter should not
be set in a production environment as the extra information is
likely to confuse users.
-.IP "\s-1BINDDN\s0 \s-1DN\s0" 4
+.IP "\fB\s-1BINDDN\s0\fR \s-1DN\s0" 4
.IX Item "BINDDN DN"
The \fB\s-1BINDDN\s0\fR parameter specifies the identity, in the form of a
Distinguished Name (\s-1DN\s0), to use when performing \s-1LDAP\s0 operations.
If not specified, \s-1LDAP\s0 operations are performed with an anonymous
identity. By default, most \s-1LDAP\s0 servers will allow anonymous access.
-.IP "\s-1BINDPW\s0 secret" 4
+.IP "\fB\s-1BINDPW\s0\fR secret" 4
.IX Item "BINDPW secret"
The \fB\s-1BINDPW\s0\fR parameter specifies the password to use when performing
\&\s-1LDAP\s0 operations. This is typically used in conjunction with the
\&\fB\s-1BINDDN\s0\fR parameter.
-.IP "\s-1ROOTBINDDN\s0 \s-1DN\s0" 4
+.IP "\fB\s-1ROOTBINDDN\s0\fR \s-1DN\s0" 4
.IX Item "ROOTBINDDN DN"
The \fB\s-1ROOTBINDDN\s0\fR parameter specifies the identity, in the form of
a Distinguished Name (\s-1DN\s0), to use when performing privileged \s-1LDAP\s0
operations, such as \fIsudoers\fR queries. The password corresponding
to the identity should be stored in \fI@ldap_secret@\fR.
If not specified, the \fB\s-1BINDDN\s0\fR identity is used (if any).
-.IP "\s-1LDAP_VERSION\s0 number" 4
+.IP "\fB\s-1LDAP_VERSION\s0\fR number" 4
.IX Item "LDAP_VERSION number"
The version of the \s-1LDAP\s0 protocol to use when connecting to the server.
The default value is protocol version 3.
-.IP "\s-1SSL\s0 on/true/yes/off/false/no" 4
+.IP "\fB\s-1SSL\s0\fR on/true/yes/off/false/no" 4
.IX Item "SSL on/true/yes/off/false/no"
If the \fB\s-1SSL\s0\fR parameter is set to \f(CW\*(C`on\*(C'\fR, \f(CW\*(C`true\*(C'\fR or \f(CW\*(C`yes\*(C'\fR, \s-1TLS\s0
(\s-1SSL\s0) encryption is always used when communicating with the \s-1LDAP\s0
server. Typically, this involves connecting to the server on port
636 (ldaps).
-.IP "\s-1SSL\s0 start_tls" 4
+.IP "\fB\s-1SSL\s0\fR start_tls" 4
.IX Item "SSL start_tls"
If the \fB\s-1SSL\s0\fR parameter is set to \f(CW\*(C`start_tls\*(C'\fR, the \s-1LDAP\s0 server
connection is initiated normally and \s-1TLS\s0 encryption is begun before
requiring a dedicated port for encrypted communications. This
parameter is only supported by \s-1LDAP\s0 servers that honor the \f(CW\*(C`start_tls\*(C'\fR
extension, such as the OpenLDAP server.
-.IP "\s-1TLS_CHECKPEER\s0 on/true/yes/off/false/no" 4
+.IP "\fB\s-1TLS_CHECKPEER\s0\fR on/true/yes/off/false/no" 4
.IX Item "TLS_CHECKPEER on/true/yes/off/false/no"
If enabled, \fB\s-1TLS_CHECKPEER\s0\fR will cause the \s-1LDAP\s0 server's \s-1TLS\s0
certificated to be verified. If the server's \s-1TLS\s0 certificate cannot
be verified (usually because it is signed by an unknown certificate
authority), \fBsudo\fR will be unable to connect to it. If \fB\s-1TLS_CHECKPEER\s0\fR
is disabled, no check is made.
-.IP "\s-1TLS_CACERTFILE\s0 file name" 4
+.IP "\fB\s-1TLS_CACERTFILE\s0\fR file name" 4
.IX Item "TLS_CACERTFILE file name"
The path to a certificate authority bundle which contains the certificates
for all the Certificate Authorities the client knows to be valid,
e.g. \fI/etc/ssl/ca\-bundle.pem\fR.
This option is only supported by the OpenLDAP libraries.
-.IP "\s-1TLS_CACERTDIR\s0 directory" 4
+.IP "\fB\s-1TLS_CACERTDIR\s0\fR directory" 4
.IX Item "TLS_CACERTDIR directory"
Similar to \fB\s-1TLS_CACERTFILE\s0\fR but instead of a file, it is a
directory containing individual Certificate Authority certificates,
The directory specified by \fB\s-1TLS_CACERTDIR\s0\fR is checked after
\&\fB\s-1TLS_CACERTFILE\s0\fR.
This option is only supported by the OpenLDAP libraries.
-.IP "\s-1TLS_CERT\s0 file name" 4
+.IP "\fB\s-1TLS_CERT\s0\fR file name" 4
.IX Item "TLS_CERT file name"
The path to a file containing the client certificate which can
be used to authenticate the client to the \s-1LDAP\s0 server.
-.RS 4
-.IP "OpenLDAP" 18
-.IX Item "OpenLDAP"
-\&\f(CW\*(C`tls_cert /etc/ssl/client_cert.pem\*(C'\fR
-.IP "Netscape-derived" 18
-.IX Item "Netscape-derived"
-\&\f(CW\*(C`tls_cert /var/ldap/cert7.db\*(C'\fR
-.RE
-.RS 4
+The certificate type depends on the \s-1LDAP\s0 libraries used.
+.Sp
+OpenLDAP:
+ \f(CW\*(C`tls_cert /etc/ssl/client_cert.pem\*(C'\fR
+.Sp
+Netscape\-derived:
+ \f(CW\*(C`tls_cert /var/ldap/cert7.db\*(C'\fR
.Sp
When using Netscape-derived libraries, this file may also contain
Certificate Authority certificates.
-.RE
-.IP "\s-1TLS_KEY\s0 file name" 4
+.IP "\fB\s-1TLS_KEY\s0\fR file name" 4
.IX Item "TLS_KEY file name"
The path to a file containing the private key which matches the
certificate specified by \fB\s-1TLS_CERT\s0\fR. The private key must not be
-password\-protected.
-.RS 4
-.IP "OpenLDAP" 18
-.IX Item "OpenLDAP"
-\&\f(CW\*(C`tls_cert /etc/ssl/client_key.pem\*(C'\fR
-.IP "Netscape-derived" 18
-.IX Item "Netscape-derived"
-\&\f(CW\*(C`tls_cert /var/ldap/key3.db\*(C'\fR
-.RE
-.RS 4
-.RE
-.IP "\s-1TLS_RANDFILE\s0 file name" 4
+password\-protected. The key type depends on the \s-1LDAP\s0 libraries
+used.
+.Sp
+OpenLDAP:
+ \f(CW\*(C`tls_cert /etc/ssl/client_key.pem\*(C'\fR
+.Sp
+Netscape\-derived:
+ \f(CW\*(C`tls_cert /var/ldap/key3.db\*(C'\fR
+.IP "\fB\s-1TLS_RANDFILE\s0\fR file name" 4
.IX Item "TLS_RANDFILE file name"
The \fB\s-1TLS_RANDFILE\s0\fR parameter specifies the path to an entropy
source for systems that lack a random device. It is generally used
in conjunction with \fIprngd\fR or \fIegd\fR.
This option is only supported by the OpenLDAP libraries.
-.IP "\s-1TLS_CIPHERS\s0 cipher list" 4
+.IP "\fB\s-1TLS_CIPHERS\s0\fR cipher list" 4
.IX Item "TLS_CIPHERS cipher list"
The \fB\s-1TLS_CIPHERS\s0\fR parameter allows the administer to restrict
which encryption algorithms may be used for \s-1TLS\s0 (\s-1SSL\s0) connections.
See the OpenSSL manual for a list of valid ciphers.
This option is only supported by the OpenLDAP libraries.
-.IP "\s-1USE_SASL\s0 on/true/yes/off/false/no" 4
+.IP "\fB\s-1USE_SASL\s0\fR on/true/yes/off/false/no" 4
.IX Item "USE_SASL on/true/yes/off/false/no"
Enable \fB\s-1USE_SASL\s0\fR for \s-1LDAP\s0 servers that support \s-1SASL\s0 authentication.
-.IP "\s-1SASL_AUTH_ID\s0 identity" 4
+.IP "\fB\s-1SASL_AUTH_ID\s0\fR identity" 4
.IX Item "SASL_AUTH_ID identity"
The \s-1SASL\s0 user name to use when connecting to the \s-1LDAP\s0 server.
By default, \fBsudo\fR will use an anonymous connection.
-.IP "\s-1ROOTUSE_SASL\s0 on/true/yes/off/false/no" 4
+.IP "\fB\s-1ROOTUSE_SASL\s0\fR on/true/yes/off/false/no" 4
.IX Item "ROOTUSE_SASL on/true/yes/off/false/no"
Enable \fB\s-1ROOTUSE_SASL\s0\fR to enable \s-1SASL\s0 authentication when connecting
to an \s-1LDAP\s0 server from a privileged process, such as \fBsudo\fR.
-.IP "\s-1ROOTSASL_AUTH_ID\s0 identity" 4
+.IP "\fB\s-1ROOTSASL_AUTH_ID\s0\fR identity" 4
.IX Item "ROOTSASL_AUTH_ID identity"
The \s-1SASL\s0 user name to use when \fB\s-1ROOTUSE_SASL\s0\fR is enabled.
-.IP "\s-1SASL_SECPROPS\s0 none/properties" 4
+.IP "\fB\s-1SASL_SECPROPS\s0\fR none/properties" 4
.IX Item "SASL_SECPROPS none/properties"
\&\s-1SASL\s0 security properties or \fInone\fR for no properties. See the
\&\s-1SASL\s0 programmer's manual for details.
-.IP "\s-1KRB5_CCNAME\s0 file name" 4
+.IP "\fB\s-1KRB5_CCNAME\s0\fR file name" 4
.IX Item "KRB5_CCNAME file name"
The path to the Kerberos 5 credential cache to use when authenticating
with the remote server.
The following sources are recognized:
.PP
.Vb 2
-\& files read sudoers from a file (usually F</etc/sudoers>)
+\& files read sudoers from F<@sysconfdir@/sudoers>
\& ldap read sudoers from LDAP
.Ve
.PP
.IX Subsection "XXX more exhaustive sudoers ldif example?"
.SH "SEE ALSO"
.IX Header "SEE ALSO"
-\&\fIldap.conf\fR\|(4), \fIsudoers\fR\|(4)
+\&\fIldap.conf\fR\|(@mansectform@), \fIsudoers\fR\|(5)
.SH "CAVEATS"
.IX Header "CAVEATS"
-parsing differences between \s-1LDAP\s0 and file sudoers
+The way that \fIsudoers\fR is parsed differs between Note that there
+are differences in the way that LDAP-based \fIsudoers\fR is parsed
+compared to file-based \fIsudoers\fR. See the \*(L"Differences between \s-1LDAP\s0 and non-LDAP sudoers\*(R" section for more information.
.SH "BUGS"
.IX Header "BUGS"
If you feel you have found a bug in \fBsudo\fR, please submit a bug report
=item *
-B<sudo> no longer needs to read I<sudoers> in its entirety. Parsing
-of F</etc/sudoers> requires the entire file to be read. When LDAP
-is used, there are only two or three LDAP queries per invocation.
+B<sudo> no longer needs to read I<sudoers> in its entirety. When
+LDAP is used, there are only two or three LDAP queries per invocation.
This makes it especially fast and particularly usable in LDAP
-environments. The first query is to parse global options (see
-below). The second is to match against the user's name and the
-groups that the user belongs to. (The special ALL tag is matched
-in this query too.) If no match is returned for the user's name
-and groups, a third query returns all entries contain user netgroups
-and checks to see if the user belongs to any of them.
+environments.
=item *
=item *
-Options inside of entries now override global default options.
-F</etc/sudoers> only supports default options and limited options
-associated with user/host/commands and aliases. The syntax is
-complicated and can be difficult for users to understand.
-
-Sudo first looks for an entry called C<cn=default> in the C<SUDOers>
-container. If found, the multi-valued C<sudoOption> attribute is
-parsed the same way the global C<Defaults> line in F</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 that override the top-level
-defaults. See the example LDAP content below for more information.
+It is possible to specify per-entry options that override the global
+default options. F<@sysconfdir@/sudoers> only supports default options and
+limited options associated with user/host/commands/aliases. The
+syntax is complicated and can be difficult for users to understand.
+Placing the options directly in the entry is more natural.
=item *
B<visudo> is no longer needed. B<visudo> provides locking and
-syntax checking of the F</etc/sudoers> file. Since LDAP updates
+syntax checking of the F<@sysconfdir@/sudoers> file. Since LDAP updates
are atomic, locking is no longer necessary. Because syntax is
checked when the data is inserted into LDAP, there is no need
for a specialized tool to check syntax.
-=item *
-
-Aliases are no longer needed. User, Host, and Cmnd Aliases were
-designed to simplify organization of I<sudoers> files and to
-improve readability. Since an LDAP I<sudoers> entry allows multiple
-values for each of its attributes, and since most LDAP browsers are
-graphical and easy to work with, these aliases are no longer
-needed.
+=back
-If you wish to specify a large number of users into an entry or
-wish to have similar entries with identical users, then either use
-groups or user netgroups. Alternately, they can all just be pasted
-into the LDAP record.
+Another major difference between LDAP and file-based I<sudoers>
+is that in LDAP, B<sudo>-specific Aliases are not supported.
-If you need to specify a large number of hosts in an entry, use
-netgroups or IP address matches (10.2.3.4/255.255.0.0). Alternately,
-they can all just be pasted into the LDAP record.
+For the most part, there is really no need for B<sudo>-specific
+Aliases. Unix groups or user netgroups can be used in place of
+User_Aliases and RunasAliases. Host netgroups can be used in place
+of HostAliases. Since Unix groups and netgroups can also be stored
+in LDAP there is no real need for B<sudo>-specific aliases.
-=back
+Cmnd_Aliases are not really required either since it is possible
+to have multiple users listed in a sudoRole. Instead of defining
+a Cmnd_Alias that is referenced by multiple users, one can create
+a sudoRole that contains the commands and assign multiple users
+to it.
=head2 SUDOers LDAP container
Sudo first looks for the C<cn=default> entry in the SUDOers container.
If found, the multi-valued C<sudoOption> attribute is parsed in the
-same manner as a global C<Defaults> line in F</etc/sudoers>. In
+same manner as a global C<Defaults> line in F<@sysconfdir@/sudoers>. In
the following example, the C<SSH_AUTH_SOCK> variable will be preserved
in the environment for all users.
=over 4
-=item sudoUser
+=item B<sudoUser>
A user name, uid (prefixed with C<'#'>), Unix group (prefixed with
a C<'%'>) or user netgroup (prefixed with a C<'+'>).
-=item sudoHost
+=item B<sudoHost>
A host name, IP address, IP network, or host netgroup (prefixed
with a C<'+'>).
The special value C<ALL> will match any host.
-=item sudoCommand
+=item B<sudoCommand>
A Unix command with optional command line arguments, potentially
including globbing characters (aka wild cards).
The special value C<ALL> will match any command.
+If a command is prefixed with an exclamation point C<'!'>, the
+user will be prohibited from running that command.
-=item sudoOption
+=item B<sudoOption>
-Similar to the global options described above, but specific to the
-C<sudoRole> in which it resides.
+Identical in function to the global options described above, but
+specific to the C<sudoRole> in which it resides.
-=item sudoRunAsUser
+=item B<sudoRunAsUser>
A user name or uid (prefixed with C<'#'>) that commands may be run
as or a Unix group (prefixed with a C<'%'>) or user netgroup (prefixed
run as.
The special value C<ALL> will match any user.
-=item sudoRunAsGroup
+=item B<sudoRunAsGroup>
A Unix group or gid (prefixed with C<'#'>) that commands may be run as.
The special value C<ALL> will match any group.
=back
-Each entry listed above contains a single value, but may be repeated
-multiple times. A sudoRole must contain at least one C<sudoUser>,
-C<sudoHost> and C<sudoCommand>.
+Each component listed above should contain a single value, but there
+may be multiple instances of each component type. A sudoRole must
+contain at least one C<sudoUser>, C<sudoHost> and C<sudoCommand>.
The following example allows users in group wheel to run any command
on any host via B<sudo>:
sudoHost: ALL
sudoCommand: ALL
+=head2 Anatomy of LDAP sudoers lookup
+
+When looking up a sudoer using LDAP there are only two or three
+LDAP queries per invocation. The first query is to parse the global
+options. The second is to match against the user's name and the
+groups that the user belongs to. (The special ALL tag is matched
+in this query too.) If no match is returned for the user's name
+and groups, a third query returns all entries containing user
+netgroups and checks to see if the user belongs to any of them.
+
=head2 Differences between LDAP and non-LDAP sudoers
There are some subtle differences in the way sudoers is handled
once in LDAP. Probably the biggest is that according to the RFC,
-LDAP's ordering is arbitrary and you cannot expect that Attributes
-and Entries are returned in any order. If there are conflicting
-command rules on an entry, the negative takes precedence. This is
-called paranoid behavior (not necessarily the most specific match).
+LDAP ordering is arbitrary and you cannot expect that Attributes
+and Entries are returned in any specific order. If there are
+conflicting command rules on an entry, the negative takes precedence.
+This is called paranoid behavior (not necessarily the most specific
+match).
Here is an example:
# Always allows all commands because ALL is matched last
puddles ALL=(root) !/bin/sh,ALL
- # LDAP equivalent of Johnny
+ # LDAP equivalent of johnny
# Allows all commands except shell
dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
objectClass: sudoRole
sudoCommand: ALL
sudoCommand: !/bin/sh
- # LDAP equivalent of Puddles
+ # LDAP equivalent of puddles
# Notice that even though ALL comes last, it still behaves like
# role1 since the LDAP code assumes the more paranoid configuration
dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
Another difference is that negations on the Host, User or Runas are
currently ignorred. For example, the following attributes do not
-do what they might appear to do.
+behave the way one might expect.
# does not match all but joe
# rather, does not match anyone
=over 4
-=item URI ldap[s]://[hostname[:port]] ...
+=item B<URI> ldap[s]://[hostname[:port]] ...
Specifies a whitespace-delimited list of one or more URIs describing
the LDAP server(s) to connect to. The I<protocol> may be either B<ldap>
The Netscape-derived libraries used on most commercial versions of
Unix are only capable of supporting one or the other.
-=item HOST name[:port] ...
+=item B<HOST> name[:port] ...
If no B<URI> is specified, the B<HOST> parameter specifies a
whitespace-delimited list of LDAP servers to connect to. Each host
B<HOST> parameter is deprecated in favor of the B<URI> specification
and is included for backwards compatibility.
-=item PORT port_number
+=item B<PORT> port_number
If no B<URI> is specified, the B<PORT> parameter specifies the
default port to connect to on the LDAP server if a B<HOST> parameter
(SSL). The B<PORT> parameter is deprecated in favor of the B<URI>
specification and is included for backwards compatibility.
-=item BIND_TIMELIMIT seconds
+=item B<BIND_TIMELIMIT> seconds
The B<BIND_TIMELIMIT> parameter specifies the amount of time, in seconds,
to wait while trying to connect to an LDAP server. If multiple B<URI>s or
B<HOST>s are specified, this is the amount of time to wait before trying
the next one in the list.
-=item TIMELIMIT seconds
+=item B<TIMELIMIT> seconds
The B<TIMELIMIT> parameter specifies the amount of time, in seconds,
to wait for a response to an LDAP query.
-=item SUDOERS_BASE base
+=item B<SUDOERS_BASE> base
The base DN to use when performing B<sudo> LDAP queries. Typically
this is of the form C<ou=SUDOers,dc=example,dc=com> for the domain
C<example.com>.
-=item SUDOERS_DEBUG debug_level
+=item B<SUDOERS_DEBUG> debug_level
This sets the debug level for B<sudo> LDAP queries. Debugging
information is printed to the standard error. A value of 1 results
be set in a production environment as the extra information is
likely to confuse users.
-=item BINDDN DN
+=item B<BINDDN> DN
The B<BINDDN> parameter specifies the identity, in the form of a
Distinguished Name (DN), to use when performing LDAP operations.
If not specified, LDAP operations are performed with an anonymous
identity. By default, most LDAP servers will allow anonymous access.
-=item BINDPW secret
+=item B<BINDPW> secret
The B<BINDPW> parameter specifies the password to use when performing
LDAP operations. This is typically used in conjunction with the
B<BINDDN> parameter.
-=item ROOTBINDDN DN
+=item B<ROOTBINDDN> DN
The B<ROOTBINDDN> parameter specifies the identity, in the form of
a Distinguished Name (DN), to use when performing privileged LDAP
to the identity should be stored in F<@ldap_secret@>.
If not specified, the B<BINDDN> identity is used (if any).
-=item LDAP_VERSION number
+=item B<LDAP_VERSION> number
The version of the LDAP protocol to use when connecting to the server.
The default value is protocol version 3.
-=item SSL on/true/yes/off/false/no
+=item B<SSL> on/true/yes/off/false/no
If the B<SSL> parameter is set to C<on>, C<true> or C<yes>, TLS
(SSL) encryption is always used when communicating with the LDAP
server. Typically, this involves connecting to the server on port
636 (ldaps).
-=item SSL start_tls
+=item B<SSL> start_tls
If the B<SSL> parameter is set to C<start_tls>, the LDAP server
connection is initiated normally and TLS encryption is begun before
parameter is only supported by LDAP servers that honor the C<start_tls>
extension, such as the OpenLDAP server.
-=item TLS_CHECKPEER on/true/yes/off/false/no
+=item B<TLS_CHECKPEER> on/true/yes/off/false/no
If enabled, B<TLS_CHECKPEER> will cause the LDAP server's TLS
certificated to be verified. If the server's TLS certificate cannot
authority), B<sudo> will be unable to connect to it. If B<TLS_CHECKPEER>
is disabled, no check is made.
-=item TLS_CACERTFILE file name
+=item B<TLS_CACERTFILE> file name
The path to a certificate authority bundle which contains the certificates
for all the Certificate Authorities the client knows to be valid,
e.g. F</etc/ssl/ca-bundle.pem>.
This option is only supported by the OpenLDAP libraries.
-=item TLS_CACERTDIR directory
+=item B<TLS_CACERTDIR> directory
Similar to B<TLS_CACERTFILE> but instead of a file, it is a
directory containing individual Certificate Authority certificates,
B<TLS_CACERTFILE>.
This option is only supported by the OpenLDAP libraries.
-=item TLS_CERT file name
+=item B<TLS_CERT> file name
The path to a file containing the client certificate which can
be used to authenticate the client to the LDAP server.
+The certificate type depends on the LDAP libraries used.
-=over 18
-
-=item OpenLDAP
-
-C<tls_cert /etc/ssl/client_cert.pem>
+OpenLDAP:
+ C<tls_cert /etc/ssl/client_cert.pem>
-=item Netscape-derived
-
-C<tls_cert /var/ldap/cert7.db>
-
-=back
+Netscape-derived:
+ C<tls_cert /var/ldap/cert7.db>
When using Netscape-derived libraries, this file may also contain
Certificate Authority certificates.
-=item TLS_KEY file name
+=item B<TLS_KEY> file name
The path to a file containing the private key which matches the
certificate specified by B<TLS_CERT>. The private key must not be
-password-protected.
+password-protected. The key type depends on the LDAP libraries
+used.
-=over 18
+OpenLDAP:
+ C<tls_cert /etc/ssl/client_key.pem>
-=item OpenLDAP
-
-C<tls_cert /etc/ssl/client_key.pem>
-
-=item Netscape-derived
-
-C<tls_cert /var/ldap/key3.db>
-
-=back
+Netscape-derived:
+ C<tls_cert /var/ldap/key3.db>
-=item TLS_RANDFILE file name
+=item B<TLS_RANDFILE> file name
The B<TLS_RANDFILE> parameter specifies the path to an entropy
source for systems that lack a random device. It is generally used
in conjunction with I<prngd> or I<egd>.
This option is only supported by the OpenLDAP libraries.
-=item TLS_CIPHERS cipher list
+=item B<TLS_CIPHERS> cipher list
The B<TLS_CIPHERS> parameter allows the administer to restrict
which encryption algorithms may be used for TLS (SSL) connections.
See the OpenSSL manual for a list of valid ciphers.
This option is only supported by the OpenLDAP libraries.
-=item USE_SASL on/true/yes/off/false/no
+=item B<USE_SASL> on/true/yes/off/false/no
Enable B<USE_SASL> for LDAP servers that support SASL authentication.
-=item SASL_AUTH_ID identity
+=item B<SASL_AUTH_ID> identity
The SASL user name to use when connecting to the LDAP server.
By default, B<sudo> will use an anonymous connection.
-=item ROOTUSE_SASL on/true/yes/off/false/no
+=item B<ROOTUSE_SASL> on/true/yes/off/false/no
Enable B<ROOTUSE_SASL> to enable SASL authentication when connecting
to an LDAP server from a privileged process, such as B<sudo>.
-=item ROOTSASL_AUTH_ID identity
+=item B<ROOTSASL_AUTH_ID> identity
The SASL user name to use when B<ROOTUSE_SASL> is enabled.
-=item SASL_SECPROPS none/properties
+=item B<SASL_SECPROPS> none/properties
SASL security properties or I<none> for no properties. See the
SASL programmer's manual for details.
-=item KRB5_CCNAME file name
+=item B<KRB5_CCNAME> file name
The path to the Kerberos 5 credential cache to use when authenticating
with the remote server.
The following sources are recognized:
- files read sudoers from a file (usually F</etc/sudoers>)
+ files read sudoers from F<@sysconfdir@/sudoers>
ldap read sudoers from LDAP
In addition, the entry C<[NOTFOUND=return]> will short-circuit the
=head1 SEE ALSO
-L<ldap.conf(4)>, L<sudoers(4)>
+L<ldap.conf(5)>, L<sudoers(5)>
=head1 CAVEATS
-parsing differences between LDAP and file sudoers
+The way that I<sudoers> is parsed differs between Note that there
+are differences in the way that LDAP-based I<sudoers> is parsed
+compared to file-based I<sudoers>. See the L<Differences between
+LDAP and non-LDAP sudoers> section for more information.
=head1 BUGS
projects / sudo / commitdiff