Annotation of embedaddon/sudo/doc/UPGRADE, revision 1.1.1.3
1.1 misho 1: Notes on upgrading from an older release
2: ========================================
3:
1.1.1.3 ! misho 4: o Upgrading from a version prior to 1.8.7:
! 5:
! 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".
! 10:
! 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.
! 15:
! 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
! 22: for details.
! 23:
1.1 misho 24: o Upgrading from a version prior to 1.8.2:
25:
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
1.1.1.3 ! misho 30: number of groups. There are a few side effects of this change.
1.1 misho 31:
32: 1) Unix groups with different names but the same group ID are
1.1.1.3 ! misho 33: can no longer be used interchangeably. Sudo will look up all
1.1 misho 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.
39:
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.
47:
48: o Upgrading from a version prior to 1.8.1:
49:
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.
53: Changes include:
54:
55: Combining multiple Defaults entries with a backslash. E.g.
56:
57: Defaults set_path \
58: Defaults syslog
59:
60: which should be:
61:
62: Defaults set_path
63: Defaults syslog
64:
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.
68:
69: Defaults set_path"foo
70:
71: In previous versions of sudo, the `"foo' portion would have
72: been ignored.
73:
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.
76:
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.
83:
84: Old style in /etc/sudoers:
85: Defaults noexec_file=/usr/local/libexec/sudo_noexec.so
86:
87: New style in /etc/sudo.conf:
88: Path noexec /usr/local/libexec/sudo_noexec.so
89:
90: o Upgrading from a version prior to 1.8.0:
91:
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.
98:
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.
104:
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
108: sudo.conf file.
109:
110: Old style in /etc/sudoers:
111: Defaults askpass=/usr/X11R6/bin/ssh-askpass
112:
113: New style in /etc/sudo.conf:
114: Path askpass /usr/X11R6/bin/ssh-askpass
115:
116: o Upgrading from a version prior to 1.7.5:
117:
118: Sudo 1.7.5 includes an updated LDAP schema with support for
119: the sudoNotBefore, sudoNotAfter and sudoOrder attributes.
120:
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.
126:
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.
133:
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.
137:
138: o Upgrading from a version prior to 1.7.4:
139:
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.
146:
147: Additionally, the tty_tickets sudoers option is now enabled by
148: default. To restore the old behavior (single time stamp per user),
149: add a line like:
150: Defaults !tty_tickets
151: to sudoers or use the --without-tty-tickets configure option.
152:
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.
161:
162: NOTE: preserving HOME has security implications since many programs
1.1.1.2 misho 163: use it when searching for configuration files. Adding HOME to env_keep
1.1 misho 164: may enable a user to run unrestricted commands via sudo.
165:
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.
170:
171: o Upgrading from a version prior to 1.7.0:
172:
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
176: group ID.
177:
178: When sudo is build with LDAP support the /etc/nsswitch.conf file is
1.1.1.3 ! misho 179: now used to determine the sudoers sea ch order. sudo will default to
1.1 misho 180: only using /etc/sudoers unless /etc/nsswitch.conf says otherwise.
181: This can be changed with an nsswitch.conf line, e.g.:
182: sudoers: ldap files
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.
186:
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:
191: tls_checkpeer no
192: in sudo's ldap.conf unless ldap.conf references a valid certificate
193: authority file(s).
194:
195: Please also see the NEWS file for a list of new features in
196: sudo 1.7.0.
197:
198: o Upgrading from a version prior to 1.6.9:
199:
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.
202:
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.
1.1.1.3 ! misho 206: Beginning with sudo 1.6.9, the environment is reset to a default
1.1 misho 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.
210:
211: Defaults env_keep += "EDITOR"
212:
213: The old behavior can be restored by negating the "env_reset"
214: option in sudoers. E.g.
215:
216: Defaults !env_reset
217:
218: There have also been changes to how the "env_keep" and
219: "env_check" options behave.
220:
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.
228:
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
1.1.1.3 ! misho 235: sufficient.
1.1 misho 236:
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.
239:
240: o Upgrading from a version prior to 1.6.8:
241:
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.
247:
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).
1.1.1.3 ! misho 252: Hopefully no one was depending on the previous (buggy) behavior.
1.1 misho 253:
254: o Upgrading from a version prior to 1.6:
255:
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
263:
264: millert ALL=(daemon) NOPASSWD:/usr/bin/whoami,/bin/ls
265:
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.
268:
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
272: example:
273:
274: millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, (root) /bin/ls, \
275: /sbin/dump
276:
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
1.1.1.3 ! misho 282: as:
1.1 misho 283:
284: millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, \
285: (root) PASSWD:/bin/ls, /sbin/dump
286:
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
291: is used.
292:
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.
296:
297: o Upgrading from a version prior to 1.5:
298:
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).
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