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