1 Notes on upgrading from an older release
2 ========================================
4 o Upgrading from a version prior to 1.8.7:
6 Sudo now stores its libexec files in a "sudo" sub-directory
7 instead of in libexec itself. For backwards compatibility, if
8 the plugin is not found in the default plugin directory, sudo
9 will check the parent directory default directory ends in "/sudo".
11 The default sudo plugins now all use the .so extension, regardless
12 of the extension used by native shared libraries. For backwards
13 compatibility, sudo on HP-UX will also search for a plugin with
14 an .sl extension if the .so version is not found.
16 Handling of users belonging to a large number of groups has
17 changed. Previously, sudo would only use the group list from
18 the kernel unless the system_group plugin was enabled in sudoers.
19 Now, sudo will query the groups database if the user belongs
20 to the maximum number of groups supported by the kernel. See
21 the group_source and max_groups settings in the sudo.conf manual
24 o Upgrading from a version prior to 1.8.2:
26 When matching Unix groups in the sudoers file, sudo will now
27 match based on the name of the group as it appears in sudoers
28 instead of the group ID. This can substantially reduce the
29 number of group lookups for sudoers files that contain a large
30 number of groups. There are a few side effects of this change.
32 1) Unix groups with different names but the same group ID are
33 can no longer be used interchangeably. Sudo will look up all
34 of a user's groups by group ID and use the resulting group
35 names when matching sudoers entries. If there are multiple
36 groups with the same ID, the group name returned by the
37 system getgrgid() library function is the name that will be
38 used when matching sudoers entries.
40 2) Unix group names specified in the sudoers file that are
41 longer than the system maximum will no longer match. For
42 instance, if there is a Unix group "fireflie" on a system
43 where group names are limited to eight characters, "%fireflies"
44 in sudoers will no longer match "fireflie". Previously, a
45 lookup by name of the group "fireflies" would have matched
46 the "fireflie" group on most systems.
48 o Upgrading from a version prior to 1.8.1:
50 Changes in the sudoers parser could result in parse errors for
51 existing sudoers file. These changes cause certain erroneous
52 entries to be flagged as errors where before they allowed.
55 Combining multiple Defaults entries with a backslash. E.g.
65 Also, double-quoted strings with a missing end-quote are now
66 detected and result in an error. Previously, text starting a
67 double quote and ending with a newline was ignored. E.g.
71 In previous versions of sudo, the `"foo' portion would have
74 To avoid problems, sudo 1.8.1's "make install" will not install
75 a new sudo binary if the existing sudoers file has errors.
77 In Sudo 1.8.1 the "noexec" functionality has moved out of the
78 sudoers policy plugin and into the sudo front-end. As a result,
79 the path to the noexec file is now specified in the sudo.conf
80 file instead of the sudoers file. If you have a sudoers file
81 that uses the "noexec_file" option, you will need to move the
82 definition to the sudo.conf file instead.
84 Old style in /etc/sudoers:
85 Defaults noexec_file=/usr/local/libexec/sudo_noexec.so
87 New style in /etc/sudo.conf:
88 Path noexec /usr/local/libexec/sudo_noexec.so
90 o Upgrading from a version prior to 1.8.0:
92 Starting with version 1.8.0, sudo uses a modular framework to
93 support policy and I/O logging plugins. The default policy
94 plugin is "sudoers" which provides the traditional sudoers
95 evaluation and I/O logging. Plugins are typically located in
96 /usr/libexec or /usr/local/libexec, though this is system-dependent.
97 The sudoers plugin is named "sudoers.so" on most systems.
99 The sudo.conf file, usually stored in /etc, is used to configure
100 plugins. This file is optional--if no plugins are specified
101 in sudo.conf, the "sudoers" plugin is used. See the sample.sudo.conf
102 file in the doc directory or refer to the updated sudo manual
103 to see how to configure sudo.conf.
105 The "askpass" setting has moved from the sudoers file to the
106 sudo.conf file. If you have a sudoers file that uses the
107 "askpass" option, you will need to move the definition to the
110 Old style in /etc/sudoers:
111 Defaults askpass=/usr/X11R6/bin/ssh-askpass
113 New style in /etc/sudo.conf:
114 Path askpass /usr/X11R6/bin/ssh-askpass
116 o Upgrading from a version prior to 1.7.5:
118 Sudo 1.7.5 includes an updated LDAP schema with support for
119 the sudoNotBefore, sudoNotAfter and sudoOrder attributes.
121 The sudoNotBefore and sudoNotAfter attribute support is only
122 used when the SUDOERS_TIMED setting is enabled in ldap.conf.
123 If enabled, those attributes are used directly when constructing
124 an LDAP filter. As a result, your LDAP server must have the
125 updated schema if you want to use sudoNotBefore and sudoNotAfter.
127 The sudoOrder support does not affect the LDAP filter sudo
128 constructs and so there is no need to explicitly enable it in
129 ldap.conf. If the sudoOrder attribute is not present in an
130 entry, a value of 0 is used. If no entries contain sudoOrder
131 attributes, the results are in whatever order the LDAP server
132 returns them, as in past versions of sudo.
134 Older versions of sudo will simply ignore the new attributes
135 if they are present in an entry. There are no compatibility
136 problems using the updated schema with older versions of sudo.
138 o Upgrading from a version prior to 1.7.4:
140 Starting with sudo 1.7.4, the time stamp files have moved from
141 /var/run/sudo to either /var/db/sudo, /var/lib/sudo or /var/adm/sudo.
142 The directories are checked for existence in that order. This
143 prevents users from receiving the sudo lecture every time the
144 system reboots. Time stamp files older than the boot time are
145 ignored on systems where it is possible to determine this.
147 Additionally, the tty_tickets sudoers option is now enabled by
148 default. To restore the old behavior (single time stamp per user),
150 Defaults !tty_tickets
151 to sudoers or use the --without-tty-tickets configure option.
153 The HOME and MAIL environment variables are now reset based on the
154 target user's password database entry when the env_reset sudoers option
155 is enabled (which is the case in the default configuration). Users
156 wishing to preserve the original values should use a sudoers entry like:
157 Defaults env_keep += HOME
158 to preserve the old value of HOME and
159 Defaults env_keep += MAIL
160 to preserve the old value of MAIL.
162 NOTE: preserving HOME has security implications since many programs
163 use it when searching for configuration files. Adding HOME to env_keep
164 may enable a user to run unrestricted commands via sudo.
166 The default syslog facility has changed from "local2" to "authpriv"
167 (or "auth" if the operating system doesn't have "authpriv").
168 The --with-logfac configure option can be used to change this
169 or it can be changed in the sudoers file.
171 o Upgrading from a version prior to 1.7.0:
173 Starting with sudo 1.7.0, comments in the sudoers file must not
174 have a digit or minus sign immediately after the comment character
175 ('#'). Otherwise, the comment may be interpreted as a user or
178 When sudo is build with LDAP support the /etc/nsswitch.conf file is
179 now used to determine the sudoers sea ch order. sudo will default to
180 only using /etc/sudoers unless /etc/nsswitch.conf says otherwise.
181 This can be changed with an nsswitch.conf line, e.g.:
183 Would case LDAP to be searched first, then the sudoers file.
184 To restore the pre-1.7.0 behavior, run configure with the
185 --with-nsswitch=no flag.
187 Sudo now ignores user .ldaprc files as well as system LDAP defaults.
188 All LDAP configuration is now in /etc/ldap.conf (or whichever file
189 was specified by configure's --with-ldap-conf-file option).
190 If you are using TLS, you may now need to specify:
192 in sudo's ldap.conf unless ldap.conf references a valid certificate
195 Please also see the NEWS file for a list of new features in
198 o Upgrading from a version prior to 1.6.9:
200 Starting with sudo 1.6.9, if an OS supports a modular authentication
201 method such as PAM, it will be used by default by configure.
203 Environment variable handling has changed significantly in sudo
204 1.6.9. Prior to version 1.6.9, sudo would preserve the user's
205 environment, pruning out potentially dangerous variables.
206 Beginning with sudo 1.6.9, the environment is reset to a default
207 set of values with only a small number of "safe" variables
208 preserved. To preserve specific environment variables, add
209 them to the "env_keep" list in sudoers. E.g.
211 Defaults env_keep += "EDITOR"
213 The old behavior can be restored by negating the "env_reset"
214 option in sudoers. E.g.
218 There have also been changes to how the "env_keep" and
219 "env_check" options behave.
221 Prior to sudo 1.6.9, the TERM and PATH environment variables
222 would always be preserved even if the env_keep option was
223 redefined. That is no longer the case. Consequently, if
224 env_keep is set with "=" and not simply appended to (i.e. using
225 "+="), PATH and TERM must be explicitly included in the list
226 of environment variables to keep. The LOGNAME, SHELL, USER,
227 and USERNAME environment variables are still always set.
229 Additionally, the env_check setting previously had no effect
230 when env_reset was set (which is now on by default). Starting
231 with sudo 1.6.9, environment variables listed in env_check are
232 also preserved in the env_reset case, provided that they do not
233 contain a '/' or '%' character. Note that it is not necessary
234 to also list a variable in env_keep--having it in env_check is
237 The default lists of variables to be preserved and/or checked
238 are displayed when sudo is run by root with the -V flag.
240 o Upgrading from a version prior to 1.6.8:
242 Prior to sudo 1.6.8, if /var/run did not exist, sudo would put
243 the time stamp files in /tmp/.odus. As of sudo 1.6.8, the
244 time stamp files will be placed in /var/adm/sudo or /usr/adm/sudo
245 if there is no /var/run directory. This directory will be
246 created if it does not already exist.
248 Previously, a sudoers entry that explicitly prohibited running
249 a command as a certain user did not override a previous entry
250 allowing the same command. This has been fixed in sudo 1.6.8
251 such that the last match is now used (as it is documented).
252 Hopefully no one was depending on the previous (buggy) behavior.
254 o Upgrading from a version prior to 1.6:
256 As of sudo 1.6, parsing of runas entries and the NOPASSWD tag
257 has changed. Prior to 1.6, a runas specifier applied only to
258 a single command directly following it. Likewise, the NOPASSWD
259 tag only allowed the command directly following it to be run
260 without a password. Starting with sudo 1.6, both the runas
261 specifier and the NOPASSWD tag are "sticky" for an entire
262 command list. So, given the following line in sudo < 1.6
264 millert ALL=(daemon) NOPASSWD:/usr/bin/whoami,/bin/ls
266 millert would be able to run /usr/bin/whoami as user daemon
267 without a password and /bin/ls as root with a password.
269 As of sudo 1.6, the same line now means that millert is able
270 to run run both /usr/bin/whoami and /bin/ls as user daemon
271 without a password. To expand on this, take the following
274 millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, (root) /bin/ls, \
277 millert can run /usr/bin/whoami as daemon and /bin/ls and
278 /sbin/dump as root. No password need be given for either
279 command. In other words, the "(root)" sets the default runas
280 user to root for the rest of the list. If we wanted to require
281 a password for /bin/ls and /sbin/dump the line could be written
284 millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, \
285 (root) PASSWD:/bin/ls, /sbin/dump
287 Additionally, sudo now uses a per-user time stamp directory
288 instead of a time stamp file. This allows tty time stamps to
289 simply be files within the user's time stamp dir. For the
290 default, non-tty case, the time stamp on the directory itself
293 Also, the temporary file used by visudo is now /etc/sudoers.tmp
294 since some versions of vipw on systems with shadow passwords use
295 /etc/stmp for the temporary shadow file.
297 o Upgrading from a version prior to 1.5:
299 By default, sudo expects the sudoers file to be mode 0440 and
300 to be owned by user and group 0. This differs from version 1.4
301 and below which expected the sudoers file to be mode 0400 and
302 to be owned by root. Doing a `make install' will set the sudoers
303 file to the new mode and group. If sudo encounters a sudoers
304 file with the old permissions it will attempt to update it to
305 the new scheme. You cannot, however, use a sudoers file with
306 the new permissions with an old sudo binary. It is suggested
307 that if have a means of distributing sudo you distribute the
308 new binaries first, then the new sudoers file (or you can leave
309 sudoers as is and sudo will fix the permissions itself as long
310 as sudoers is on a local file system).