mir/sudo
2
0
Fork 0
mirror of https://github.com/sudo-project/sudo.git synced 2025-08-30 05:48:18 +00:00
Code Issues Releases Wiki Activity

Reorganize the first section a bit. Substitute the proper path for

Browse Source 
/etc/sudoers.
This commit is contained in:
Todd C. Miller 2008-01-20 21:18:56 +00:00
parent e1db0d126f
commit a48e85e1ab
3 changed files with 331 additions and 351 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

262
sudoers.ldap.cat
View File

@ -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,6 +41,24 @@ 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
@ -70,25 +70,6 @@ DDEESSCCRRIIPPTTIIOONN
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.
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
The _s_u_d_o_e_r_s configuration is contained in the ou=SUDOers
@ -111,19 +92,38 @@ 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.
ssuuddooRRuunnAAssGGrroouupp
A Unix group or gid (prefixed with '#') that commands
@ -136,27 +136,13 @@ SUDOERS.LDAP(4) MAINTENANCE COMMANDS SUDOERS.LDAP(4)
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.
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

210
sudoers.ldap.man.in
View File

@ -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

210
sudoers.ldap.pod
View File

@ -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,49 +49,37 @@ 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.
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.
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.
=back
Another major difference between LDAP and file-based I<sudoers>
is that in LDAP, B<sudo>-specific Aliases are not supported.
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.
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
The I<sudoers> configuration is contained in the C<ou=SUDOers> LDAP
@ -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
OpenLDAP:
C<tls_cert /etc/ssl/client_cert.pem>
=item 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
Netscape-derived:
C<tls_cert /var/ldap/key3.db>
C<tls_cert /etc/ssl/client_key.pem>
=item Netscape-derived
C<tls_cert /var/ldap/key3.db>
=back
=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