From: Todd C. Miller <Todd.Miller@courtesan.com>
Date: Sun, 20 Jan 2008 21:18:56 +0000 (+0000)
Subject: Reorganize the first section a bit. Substitute the proper path for
X-Git-Tag: SUDO_1_7_0~216
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=a48e85e1ab04aeeafd5ed7542863bbf7859e1cfe;p=sudo
Reorganize the first section a bit. Substitute the proper path for
/etc/sudoers.
---
diff --git a/sudoers.ldap.cat b/sudoers.ldap.cat
index 590aecbd0..d650c33ec 100644
--- a/sudoers.ldap.cat
+++ b/sudoers.ldap.cat
@@ -15,17 +15,9 @@ DDEESSCCRRIIPPTTIIOONN
Using LDAP for _s_u_d_o_e_r_s has several benefits:
+o ssuuddoo no longer needs to read _s_u_d_o_e_r_s in its entirety.
- Parsing of _/_e_t_c_/_s_u_d_o_e_r_s 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.
+o ssuuddoo no longer exits if there is a typo in _s_u_d_o_e_r_s.
It is not possible to load LDAP data into the server
@@ -34,23 +26,13 @@ DDEESSCCRRIIPPTTIIOONN
typos in a user or host name, but this will not pre-
vent ssuuddoo from running.
- +o Options inside of entries now override global default
- options. _/_e_t_c_/_s_u_d_o_e_r_s 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 _/_e_t_c_/_s_u_d_o_e_r_s 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.
+ +o It is possible to specify per-entry options that over-
+ ride the global default options. _/_e_t_c_/_s_u_d_o_e_r_s 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.
+o vviissuuddoo is no longer needed. vviissuuddoo provides locking
and syntax checking of the _/_e_t_c_/_s_u_d_o_e_r_s file. Since
@@ -59,35 +41,34 @@ DDEESSCCRRIIPPTTIIOONN
inserted into LDAP, there is no need for a specialized
tool to check syntax.
+ Another major difference between LDAP and file-based _s_u_d_o_-
+ _e_r_s is that in LDAP, ssuuddoo-specific Aliases are not sup-
+ ported.
+ For the most part, there is really no need for ssuuddoo-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 ssuuddoo-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)
- +o Aliases are no longer needed. User, Host, and Cmnd
- Aliases were designed to simplify organization of
- _s_u_d_o_e_r_s files and to improve readability. Since an
- LDAP _s_u_d_o_e_r_s 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.
SSUUDDOOeerrss LLDDAAPP ccoonnttaaiinneerr
@@ -111,52 +92,57 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
The equivalent of a sudoer in LDAP is a sudoRole. It con-
sists of the following components:
- sudoUser
+ ssuuddooUUsseerr
A user name, uid (prefixed with '#'), Unix group (pre-
fixed with a '%') or user netgroup (prefixed with a
'+').
- sudoHost
+ ssuuddooHHoosstt
A host name, IP address, IP network, or host netgroup
(prefixed with a '+'). The special value ALL will
match any host.
- sudoCommand
+ ssuuddooCCoommmmaanndd
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.
+ ssuuddooOOppttiioonn
+ Identical in function to the global options described
+ above, but specific to the sudoRole in which it
+ resides.
+ ssuuddooRRuunnAAssUUsseerr
+ 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
+ ssuuddooRRuunnAAssGGrroouupp
+ 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 ssuuddoo:
@@ -169,16 +155,27 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
sudoHost: ALL
sudoCommand: ALL
+ AAnnaattoommyy ooff LLDDAAPP ssuuddooeerrss llooookkuupp
+
+ 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.
+
DDiiffffeerreenncceess bbeettwweeeenn LLDDAAPP aanndd nnoonn--LLDDAAPP ssuuddooeerrss
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:
@@ -193,6 +190,9 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
+
+
+
1.7 January 20, 2008 3
@@ -202,7 +202,7 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
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
@@ -213,7 +213,7 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
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
@@ -227,7 +227,7 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
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
@@ -286,7 +286,7 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
options are listed below in upper case but are parsed in a
case-independent manner.
- URI ldap[s]://[hostname[:port]] ...
+ UURRII ldap[s]://[hostname[:port]] ...
Specifies a whitespace-delimited list of one or more
URIs describing the LDAP server(s) to connect to. The
_p_r_o_t_o_c_o_l may be either llddaapp or llddaappss, the latter being
@@ -299,7 +299,7 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
libraries used on most commercial versions of Unix are
only capable of supporting one or the other.
- HOST name[:port] ...
+ HHOOSSTT name[:port] ...
If no UURRII is specified, the HHOOSSTT parameter specifies a
whitespace-delimited list of LDAP servers to connect
to. Each host may include an optional _p_o_r_t separated
@@ -307,7 +307,7 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
favor of the UURRII specification and is included for
backwards compatibility.
- PORT port_number
+ PPOORRTT port_number
If no UURRII is specified, the PPOORRTT parameter specifies
the default port to connect to on the LDAP server if a
HHOOSSTT parameter does not specify the port itself. If
@@ -316,7 +316,7 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
parameter is deprecated in favor of the UURRII specifica-
tion and is included for backwards compatibility.
- BIND_TIMELIMIT seconds
+ BBIINNDD__TTIIMMEELLIIMMIITT seconds
The BBIINNDD__TTIIMMEELLIIMMIITT parameter specifies the amount of
time, in seconds, to wait while trying to connect to
an LDAP server. If multiple UURRIIs or HHOOSSTTs are speci-
@@ -334,16 +334,16 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
- TIMELIMIT seconds
+ TTIIMMEELLIIMMIITT seconds
The TTIIMMEELLIIMMIITT parameter specifies the amount of time,
in seconds, to wait for a response to an LDAP query.
- SUDOERS_BASE base
+ SSUUDDOOEERRSS__BBAASSEE base
The base DN to use when performing ssuuddoo LDAP queries.
Typically this is of the form ou=SUDOers,dc=exam-
ple,dc=com for the domain example.com.
- SUDOERS_DEBUG debug_level
+ SSUUDDOOEERRSS__DDEEBBUUGG debug_level
This sets the debug level for ssuuddoo LDAP queries.
Debugging information is printed to the standard
error. A value of 1 results in a moderate amount of
@@ -352,7 +352,7 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
be set in a production environment as the extra infor-
mation is likely to confuse users.
- BINDDN DN
+ BBIINNDDDDNN DN
The BBIINNDDDDNN parameter specifies the identity, in the
form of a Distinguished Name (DN), to use when per-
forming LDAP operations. If not specified, LDAP oper-
@@ -360,12 +360,12 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
default, most LDAP servers will allow anonymous
access.
- BINDPW secret
+ BBIINNDDPPWW secret
The BBIINNDDPPWW parameter specifies the password to use
when performing LDAP operations. This is typically
used in conjunction with the BBIINNDDDDNN parameter.
- ROOTBINDDN DN
+ RROOOOTTBBIINNDDDDNN DN
The RROOOOTTBBIINNDDDDNN parameter specifies the identity, in
the form of a Distinguished Name (DN), to use when
performing privileged LDAP operations, such as _s_u_d_o_e_r_s
@@ -373,18 +373,18 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
should be stored in _/_e_t_c_/_l_d_a_p_._s_e_c_r_e_t. If not speci-
fied, the BBIINNDDDDNN identity is used (if any).
- LDAP_VERSION number
+ LLDDAAPP__VVEERRSSIIOONN 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
+ SSSSLL on/true/yes/off/false/no
If the SSSSLL 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
+ SSSSLL start_tls
If the SSSSLL parameter is set to start_tls, the LDAP
server connection is initiated normally and TLS
encryption is begun before the bind credentials are
@@ -405,7 +405,7 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
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
+ TTLLSS__CCHHEECCKKPPEEEERR on/true/yes/off/false/no
If enabled, TTLLSS__CCHHEECCKKPPEEEERR will cause the LDAP server's
TLS certificated to be verified. If the server's TLS
certificate cannot be verified (usually because it is
@@ -413,14 +413,14 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
be unable to connect to it. If TTLLSS__CCHHEECCKKPPEEEERR is dis-
abled, no check is made.
- TLS_CACERTFILE file name
+ TTLLSS__CCAACCEERRTTFFIILLEE 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.
_/_e_t_c_/_s_s_l_/_c_a_-_b_u_n_d_l_e_._p_e_m. This option is only supported
by the OpenLDAP libraries.
- TLS_CACERTDIR directory
+ TTLLSS__CCAACCEERRTTDDIIRR directory
Similar to TTLLSS__CCAACCEERRTTFFIILLEE but instead of a file, it is
a directory containing individual Certificate Author-
ity certificates, e.g. _/_e_t_c_/_s_s_l_/_c_e_r_t_s. The directory
@@ -428,32 +428,32 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
EERRTTFFIILLEE. This option is only supported by the OpenL-
DAP libraries.
- TLS_CERT file name
+ TTLLSS__CCEERRTT 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
+ TTLLSS__KKEEYY file name
The path to a file containing the private key which
matches the certificate specified by TTLLSS__CCEERRTT. 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 TTLLSS__RRAANNDDFFIILLEE parameter specifies the path to an
- entropy source for systems that lack a random device.
- It is generally used in conjunction with _p_r_n_g_d or _e_g_d.
- This option is only supported by the OpenLDAP
+ Netscape-derived:
+ tls_cert /var/ldap/key3.db
@@ -466,38 +466,43 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
+ TTLLSS__RRAANNDDFFIILLEE file name
+ The TTLLSS__RRAANNDDFFIILLEE parameter specifies the path to an
+ entropy source for systems that lack a random device.
+ It is generally used in conjunction with _p_r_n_g_d or _e_g_d.
+ This option is only supported by the OpenLDAP
libraries.
- TLS_CIPHERS cipher list
+ TTLLSS__CCIIPPHHEERRSS cipher list
The TTLLSS__CCIIPPHHEERRSS 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
+ UUSSEE__SSAASSLL on/true/yes/off/false/no
Enable UUSSEE__SSAASSLL for LDAP servers that support SASL
authentication.
- SASL_AUTH_ID identity
+ SSAASSLL__AAUUTTHH__IIDD identity
The SASL user name to use when connecting to the LDAP
server. By default, ssuuddoo will use an anonymous con-
nection.
- ROOTUSE_SASL on/true/yes/off/false/no
+ RROOOOTTUUSSEE__SSAASSLL on/true/yes/off/false/no
Enable RROOOOTTUUSSEE__SSAASSLL to enable SASL authentication when
connecting to an LDAP server from a privileged pro-
cess, such as ssuuddoo.
- ROOTSASL_AUTH_ID identity
+ RROOOOTTSSAASSLL__AAUUTTHH__IIDD identity
The SASL user name to use when RROOOOTTUUSSEE__SSAASSLL is
enabled.
- SASL_SECPROPS none/properties
+ SSAASSLL__SSEECCPPRROOPPSS none/properties
SASL security properties or _n_o_n_e for no properties.
See the SASL programmer's manual for details.
- KRB5_CCNAME file name
+ KKRRBB55__CCCCNNAAMMEE file name
The path to the Kerberos 5 credential cache to use
when authenticating with the remote server.
@@ -514,12 +519,7 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
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.
@@ -532,6 +532,13 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
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:
@@ -574,13 +581,6 @@ EEXXAAMMPPLLEESS
-
-
-
-
-
-
-
@@ -803,10 +803,14 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
SSEEEE AALLSSOO
- _l_d_a_p_._c_o_n_f(4), _s_u_d_o_e_r_s(4)
+ _l_d_a_p_._c_o_n_f(4), _s_u_d_o_e_r_s(5)
CCAAVVEEAATTSS
- parsing differences between LDAP and file sudoers
+ The way that _s_u_d_o_e_r_s is parsed differs between Note that
+ there are differences in the way that LDAP-based _s_u_d_o_e_r_s
+ is parsed compared to file-based _s_u_d_o_e_r_s. See the "Dif-
+ ferences between LDAP and non-LDAP sudoers" section for
+ more information.
BBUUGGSS
If you feel you have found a bug in ssuuddoo, please submit a
@@ -844,10 +848,6 @@ DDIISSCCLLAAIIMMEERR
-
-
-
-
diff --git a/sudoers.ldap.man.in b/sudoers.ldap.man.in
index d1952a680..a9ba18438 100644
--- a/sudoers.ldap.man.in
+++ b/sudoers.ldap.man.in
@@ -157,16 +157,10 @@ in a large, distributed environment.
.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
@@ -174,42 +168,32 @@ not conform to the sudoers schema, so proper syntax is guaranteed.
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
@@ -217,7 +201,7 @@ container.
.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
@@ -232,39 +216,41 @@ in the environment for all users.
.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:
@@ -278,14 +264,24 @@ 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
@@ -298,7 +294,7 @@ Here is an example:
.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
@@ -311,7 +307,7 @@ Here is an example:
.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
@@ -326,7 +322,7 @@ Here is an example:
.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
@@ -374,7 +370,7 @@ values specified in \fI/etc/openldap/ldap.conf\fR or the user's
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
@@ -385,14 +381,14 @@ encryption. If no \fIport\fR is specified, the default is port 389 for
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
@@ -400,22 +396,22 @@ does not specify the port itself. If no \fB\s-1PORT\s0\fR parameter is used,
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
@@ -423,35 +419,35 @@ in a moderate amount of debugging information. A value of 2 shows
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
@@ -459,20 +455,20 @@ the bind credentials are sent. This has the advantage of not
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,
@@ -480,69 +476,63 @@ e.g. \fI/etc/ssl/certs\fR.
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.
@@ -559,7 +549,7 @@ match and later matches take precedence over earlier ones.
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
@@ -775,10 +765,12 @@ schema directory (e.g. \fI/etc/openldap/schema\fR), add the proper
.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
diff --git a/sudoers.ldap.pod b/sudoers.ldap.pod
index 000b860e0..64b969a4d 100644
--- a/sudoers.ldap.pod
+++ b/sudoers.ldap.pod
@@ -34,16 +34,10 @@ Using LDAP for I<sudoers> has several benefits:
=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 *
@@ -55,48 +49,36 @@ this will not prevent B<sudo> from running.
=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
@@ -105,7 +87,7 @@ 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.
@@ -121,29 +103,31 @@ the following components:
=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
@@ -151,16 +135,16 @@ with a C<'+'>) that contains a list of users that commands may be
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>:
@@ -173,14 +157,25 @@ 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:
@@ -190,7 +185,7 @@ 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
@@ -201,7 +196,7 @@ Here is an example:
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
@@ -215,7 +210,7 @@ Here is an example:
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
@@ -262,7 +257,7 @@ below in upper case but are parsed in a case-independent manner.
=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>
@@ -274,7 +269,7 @@ libraries support the mixing of C<ldap://> and C<ldaps://> URIs.
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
@@ -282,7 +277,7 @@ may include an optional I<port> separated by a colon (':'). The
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
@@ -291,25 +286,25 @@ the default is port 389 for LDAP and port 636 for LDAP over TLS
(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
@@ -318,20 +313,20 @@ 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.
-=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
@@ -339,19 +334,19 @@ operations, such as I<sudoers> queries. The password corresponding
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
@@ -360,7 +355,7 @@ requiring a dedicated port for encrypted communications. This
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
@@ -368,14 +363,14 @@ be verified (usually because it is signed by an unknown certificate
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,
@@ -384,82 +379,72 @@ The directory specified by B<TLS_CACERTDIR> is checked after
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.
@@ -478,7 +463,7 @@ match and later matches take precedence over earlier ones.
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
@@ -678,11 +663,14 @@ C<include> line in C<slapd.conf> and restart B<slapd>.
=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