1 Notes on upgrading from an older release
2 ========================================
4 o Upgrading from a version prior to 1.8.2:
6 When matching Unix groups in the sudoers file, sudo will now
7 match based on the name of the group as it appears in sudoers
8 instead of the group ID. This can substantially reduce the
9 number of group lookups for sudoers files that contain a large
10 nummber of groups. There are a few side effects of this change.
12 1) Unix groups with different names but the same group ID are
13 can no longer be used interchangably. Sudo will look up all
14 of a user's groups by group ID and use the resulting group
15 names when matching sudoers entries. If there are multiple
16 groups with the same ID, the group name returned by the
17 system getgrgid() library function is the name that will be
18 used when matching sudoers entries.
20 2) Unix group names specified in the sudoers file that are
21 longer than the system maximum will no longer match. For
22 instance, if there is a Unix group "fireflie" on a system
23 where group names are limited to eight characters, "%fireflies"
24 in sudoers will no longer match "fireflie". Previously, a
25 lookup by name of the group "fireflies" would have matched
26 the "fireflie" group on most systems.
28 o Upgrading from a version prior to 1.8.1:
30 Changes in the sudoers parser could result in parse errors for
31 existing sudoers file. These changes cause certain erroneous
32 entries to be flagged as errors where before they allowed.
35 Combining multiple Defaults entries with a backslash. E.g.
45 Also, double-quoted strings with a missing end-quote are now
46 detected and result in an error. Previously, text starting a
47 double quote and ending with a newline was ignored. E.g.
51 In previous versions of sudo, the `"foo' portion would have
54 To avoid problems, sudo 1.8.1's "make install" will not install
55 a new sudo binary if the existing sudoers file has errors.
57 In Sudo 1.8.1 the "noexec" functionality has moved out of the
58 sudoers policy plugin and into the sudo front-end. As a result,
59 the path to the noexec file is now specified in the sudo.conf
60 file instead of the sudoers file. If you have a sudoers file
61 that uses the "noexec_file" option, you will need to move the
62 definition to the sudo.conf file instead.
64 Old style in /etc/sudoers:
65 Defaults noexec_file=/usr/local/libexec/sudo_noexec.so
67 New style in /etc/sudo.conf:
68 Path noexec /usr/local/libexec/sudo_noexec.so
70 o Upgrading from a version prior to 1.8.0:
72 Starting with version 1.8.0, sudo uses a modular framework to
73 support policy and I/O logging plugins. The default policy
74 plugin is "sudoers" which provides the traditional sudoers
75 evaluation and I/O logging. Plugins are typically located in
76 /usr/libexec or /usr/local/libexec, though this is system-dependent.
77 The sudoers plugin is named "sudoers.so" on most systems.
79 The sudo.conf file, usually stored in /etc, is used to configure
80 plugins. This file is optional--if no plugins are specified
81 in sudo.conf, the "sudoers" plugin is used. See the sample.sudo.conf
82 file in the doc directory or refer to the updated sudo manual
83 to see how to configure sudo.conf.
85 The "askpass" setting has moved from the sudoers file to the
86 sudo.conf file. If you have a sudoers file that uses the
87 "askpass" option, you will need to move the definition to the
90 Old style in /etc/sudoers:
91 Defaults askpass=/usr/X11R6/bin/ssh-askpass
93 New style in /etc/sudo.conf:
94 Path askpass /usr/X11R6/bin/ssh-askpass
96 o Upgrading from a version prior to 1.7.5:
98 Sudo 1.7.5 includes an updated LDAP schema with support for
99 the sudoNotBefore, sudoNotAfter and sudoOrder attributes.
101 The sudoNotBefore and sudoNotAfter attribute support is only
102 used when the SUDOERS_TIMED setting is enabled in ldap.conf.
103 If enabled, those attributes are used directly when constructing
104 an LDAP filter. As a result, your LDAP server must have the
105 updated schema if you want to use sudoNotBefore and sudoNotAfter.
107 The sudoOrder support does not affect the LDAP filter sudo
108 constructs and so there is no need to explicitly enable it in
109 ldap.conf. If the sudoOrder attribute is not present in an
110 entry, a value of 0 is used. If no entries contain sudoOrder
111 attributes, the results are in whatever order the LDAP server
112 returns them, as in past versions of sudo.
114 Older versions of sudo will simply ignore the new attributes
115 if they are present in an entry. There are no compatibility
116 problems using the updated schema with older versions of sudo.
118 o Upgrading from a version prior to 1.7.4:
120 Starting with sudo 1.7.4, the time stamp files have moved from
121 /var/run/sudo to either /var/db/sudo, /var/lib/sudo or /var/adm/sudo.
122 The directories are checked for existence in that order. This
123 prevents users from receiving the sudo lecture every time the
124 system reboots. Time stamp files older than the boot time are
125 ignored on systems where it is possible to determine this.
127 Additionally, the tty_tickets sudoers option is now enabled by
128 default. To restore the old behavior (single time stamp per user),
130 Defaults !tty_tickets
131 to sudoers or use the --without-tty-tickets configure option.
133 The HOME and MAIL environment variables are now reset based on the
134 target user's password database entry when the env_reset sudoers option
135 is enabled (which is the case in the default configuration). Users
136 wishing to preserve the original values should use a sudoers entry like:
137 Defaults env_keep += HOME
138 to preserve the old value of HOME and
139 Defaults env_keep += MAIL
140 to preserve the old value of MAIL.
142 NOTE: preserving HOME has security implications since many programs
143 use when searching for configuration files. Adding HOME to env_keep
144 may enable a user to run unrestricted commands via sudo.
146 The default syslog facility has changed from "local2" to "authpriv"
147 (or "auth" if the operating system doesn't have "authpriv").
148 The --with-logfac configure option can be used to change this
149 or it can be changed in the sudoers file.
151 o Upgrading from a version prior to 1.7.0:
153 Starting with sudo 1.7.0, comments in the sudoers file must not
154 have a digit or minus sign immediately after the comment character
155 ('#'). Otherwise, the comment may be interpreted as a user or
158 When sudo is build with LDAP support the /etc/nsswitch.conf file is
159 now used to determine the sudoers seach order. sudo will default to
160 only using /etc/sudoers unless /etc/nsswitch.conf says otherwise.
161 This can be changed with an nsswitch.conf line, e.g.:
163 Would case LDAP to be searched first, then the sudoers file.
164 To restore the pre-1.7.0 behavior, run configure with the
165 --with-nsswitch=no flag.
167 Sudo now ignores user .ldaprc files as well as system LDAP defaults.
168 All LDAP configuration is now in /etc/ldap.conf (or whichever file
169 was specified by configure's --with-ldap-conf-file option).
170 If you are using TLS, you may now need to specify:
172 in sudo's ldap.conf unless ldap.conf references a valid certificate
175 Please also see the NEWS file for a list of new features in
178 o Upgrading from a version prior to 1.6.9:
180 Starting with sudo 1.6.9, if an OS supports a modular authentication
181 method such as PAM, it will be used by default by configure.
183 Environment variable handling has changed significantly in sudo
184 1.6.9. Prior to version 1.6.9, sudo would preserve the user's
185 environment, pruning out potentially dangerous variables.
186 Beginning with sudo 1.6.9, the envionment is reset to a default
187 set of values with only a small number of "safe" variables
188 preserved. To preserve specific environment variables, add
189 them to the "env_keep" list in sudoers. E.g.
191 Defaults env_keep += "EDITOR"
193 The old behavior can be restored by negating the "env_reset"
194 option in sudoers. E.g.
198 There have also been changes to how the "env_keep" and
199 "env_check" options behave.
201 Prior to sudo 1.6.9, the TERM and PATH environment variables
202 would always be preserved even if the env_keep option was
203 redefined. That is no longer the case. Consequently, if
204 env_keep is set with "=" and not simply appended to (i.e. using
205 "+="), PATH and TERM must be explicitly included in the list
206 of environment variables to keep. The LOGNAME, SHELL, USER,
207 and USERNAME environment variables are still always set.
209 Additionally, the env_check setting previously had no effect
210 when env_reset was set (which is now on by default). Starting
211 with sudo 1.6.9, environment variables listed in env_check are
212 also preserved in the env_reset case, provided that they do not
213 contain a '/' or '%' character. Note that it is not necessary
214 to also list a variable in env_keep--having it in env_check is
217 The default lists of variables to be preserved and/or checked
218 are displayed when sudo is run by root with the -V flag.
220 o Upgrading from a version prior to 1.6.8:
222 Prior to sudo 1.6.8, if /var/run did not exist, sudo would put
223 the time stamp files in /tmp/.odus. As of sudo 1.6.8, the
224 time stamp files will be placed in /var/adm/sudo or /usr/adm/sudo
225 if there is no /var/run directory. This directory will be
226 created if it does not already exist.
228 Previously, a sudoers entry that explicitly prohibited running
229 a command as a certain user did not override a previous entry
230 allowing the same command. This has been fixed in sudo 1.6.8
231 such that the last match is now used (as it is documented).
232 Hopefully no one was depending on the previous (buggy) beghavior.
234 o Upgrading from a version prior to 1.6:
236 As of sudo 1.6, parsing of runas entries and the NOPASSWD tag
237 has changed. Prior to 1.6, a runas specifier applied only to
238 a single command directly following it. Likewise, the NOPASSWD
239 tag only allowed the command directly following it to be run
240 without a password. Starting with sudo 1.6, both the runas
241 specifier and the NOPASSWD tag are "sticky" for an entire
242 command list. So, given the following line in sudo < 1.6
244 millert ALL=(daemon) NOPASSWD:/usr/bin/whoami,/bin/ls
246 millert would be able to run /usr/bin/whoami as user daemon
247 without a password and /bin/ls as root with a password.
249 As of sudo 1.6, the same line now means that millert is able
250 to run run both /usr/bin/whoami and /bin/ls as user daemon
251 without a password. To expand on this, take the following
254 millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, (root) /bin/ls, \
257 millert can run /usr/bin/whoami as daemon and /bin/ls and
258 /sbin/dump as root. No password need be given for either
259 command. In other words, the "(root)" sets the default runas
260 user to root for the rest of the list. If we wanted to require
261 a password for /bin/ls and /sbin/dump the line could be written
264 millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, \
265 (root) PASSWD:/bin/ls, /sbin/dump
267 Additionally, sudo now uses a per-user time stamp directory
268 instead of a time stamp file. This allows tty time stamps to
269 simply be files within the user's time stamp dir. For the
270 default, non-tty case, the time stamp on the directory itself
273 Also, the temporary file used by visudo is now /etc/sudoers.tmp
274 since some versions of vipw on systems with shadow passwords use
275 /etc/stmp for the temporary shadow file.
277 o Upgrading from a version prior to 1.5:
279 By default, sudo expects the sudoers file to be mode 0440 and
280 to be owned by user and group 0. This differs from version 1.4
281 and below which expected the sudoers file to be mode 0400 and
282 to be owned by root. Doing a `make install' will set the sudoers
283 file to the new mode and group. If sudo encounters a sudoers
284 file with the old permissions it will attempt to update it to
285 the new scheme. You cannot, however, use a sudoers file with
286 the new permissions with an old sudo binary. It is suggested
287 that if have a means of distributing sudo you distribute the
288 new binaries first, then the new sudoers file (or you can leave
289 sudoers as is and sudo will fix the permissions itself as long
290 as sudoers is on a local file system).