1Notes on upgrading from an older release
2========================================
3
4o Upgrading from a version prior to 1.7.6:
5
6    Changes in the sudoers parser could result in parse errors for
7    existing sudoers file.  These changes cause certain erroneous
8    entries to be flagged as errors where before they allowed.
9    Changes include:
10
11    Combining multiple Defaults entries with a backslash.  E.g.
12
13	Defaults set_path \
14	Defaults syslog
15
16    which should be:
17
18	Defaults set_path
19	Defaults syslog
20
21    Also, double-quoted strings with a missing end-quote are now
22    detected and result in an error.  Previously, text starting a
23    double quote and ending with a newline was ignored.  E.g.
24
25	Defaults set_path"foo
26
27    In previous versions of sudo, the `"foo' portion would have
28    been ignored.
29
30    To avoid problems, sudo 1.8.1's "make install" will not install
31    a new sudo binary if the existing sudoers file has errors.
32
33o Upgrading from a version prior to 1.7.5:
34
35    Sudo 1.7.5 includes an updated LDAP schema with support for
36    the sudoNotBefore, sudoNotAfter and sudoOrder attributes.
37
38    The sudoNotBefore and sudoNotAfter attribute support is only
39    used when the SUDOERS_TIMED setting is enabled in ldap.conf.
40    If enabled, those attributes are used directly when constructing
41    an LDAP filter.  As a result, your LDAP server must have the
42    updated schema if you want to use sudoNotBefore and sudoNotAfter.
43
44    The sudoOrder support does not affect the LDAP filter sudo
45    constructs and so there is no need to explicitly enable it in
46    ldap.conf.  If the sudoOrder attribute is not present in an
47    entry, a value of 0 is used.  If no entries contain sudoOrder
48    attributes, the results are in whatever order the LDAP server
49    returns them, as in past versions of sudo.
50
51    Older versions of sudo will simply ignore the new attributes
52    if they are present in an entry.  There are no compatibility
53    problems using the updated schema with older versions of sudo.
54
55o Upgrading from a version prior to 1.7.4:
56
57    Starting with sudo 1.7.4, the time stamp files have moved from
58    /var/run/sudo to either /var/db/sudo, /var/lib/sudo or /var/adm/sudo.
59    The directories are checked for existence in that order.  This
60    prevents users from receiving the sudo lecture every time the
61    system reboots.  Time stamp files older than the boot time are
62    ignored on systems where it is possible to determine this.
63
64    Additionally, the tty_tickets sudoers option is now enabled by
65    default.  To restore the old behavior (single time stamp per user),
66    add a line like:
67	Defaults !tty_tickets
68    to sudoers or use the --without-tty-tickets configure option.
69
70    The HOME and MAIL environment variables are now reset based on the
71    target user's password database entry when the env_reset sudoers option
72    is enabled (which is the case in the default configuration).  Users
73    wishing to preserve the original values should use a sudoers entry like:
74        Defaults env_keep += HOME
75    to preserve the old value of HOME and
76        Defaults env_keep += MAIL
77    to preserve the old value of MAIL.
78
79    NOTE: preserving HOME has security implications since many programs
80    use it when searching for configuration files.  Adding HOME to env_keep
81    may enable a user to run unrestricted commands via sudo.
82
83    The default syslog facility has changed from "local2" to "authpriv"
84    (or "auth" if the operating system doesn't have "authpriv").
85    The --with-logfac configure option can be used to change this
86    or it can be changed in the sudoers file.
87
88o Upgrading from a version prior to 1.7.0:
89
90    Starting with sudo 1.7.0, comments in the sudoers file must not
91    have a digit or minus sign immediately after the comment character
92    ('#').  Otherwise, the comment may be interpreted as a user or
93    group ID.
94
95    When sudo is build with LDAP support the /etc/nsswitch.conf file is
96    now used to determine the sudoers seach order.  sudo will default to
97    only using /etc/sudoers unless /etc/nsswitch.conf says otherwise.
98    This can be changed with an nsswitch.conf line, e.g.:
99        sudoers:        ldap files
100    Would case LDAP to be searched first, then the sudoers file.
101    To restore the pre-1.7.0 behavior, run configure with the
102    --with-nsswitch=no flag.
103
104    Sudo now ignores user .ldaprc files as well as system LDAP defaults.
105    All LDAP configuration is now in /etc/ldap.conf (or whichever file
106    was specified by configure's --with-ldap-conf-file option).
107    If you are using TLS, you may now need to specify:
108	tls_checkpeer no
109    in sudo's ldap.conf unless ldap.conf references a valid certificate
110    authority file(s).
111
112    Please also see the NEWS file for a list of new features in
113    sudo 1.7.0.
114
115o Upgrading from a version prior to 1.6.9:
116
117    Starting with sudo 1.6.9, if an OS supports a modular authentication
118    method such as PAM, it will be used by default by configure.
119
120    Environment variable handling has changed significantly in sudo
121    1.6.9.  Prior to version 1.6.9, sudo would preserve the user's
122    environment, pruning out potentially dangerous variables.
123    Beginning with sudo 1.6.9, the envionment is reset to a default
124    set of values with only a small number of "safe" variables
125    preserved.  To preserve specific environment variables, add
126    them to the "env_keep" list in sudoers.  E.g.
127
128	Defaults env_keep += "EDITOR"
129
130    The old behavior can be restored by negating the "env_reset"
131    option in sudoers.  E.g.
132
133	Defaults !env_reset
134
135    There have  also been changes to how the "env_keep" and
136    "env_check" options behave.
137
138    Prior to sudo 1.6.9, the TERM and PATH environment variables
139    would always be preserved even if the env_keep option was
140    redefined.  That is no longer the case.  Consequently, if
141    env_keep is set with "=" and not simply appended to (i.e. using
142    "+="), PATH and TERM must be explicitly included in the list
143    of environment variables to keep.  The LOGNAME, SHELL, USER,
144    and USERNAME environment variables are still always set.
145
146    Additionally, the env_check setting previously had no effect
147    when env_reset was set (which is now on by default).  Starting
148    with sudo 1.6.9, environment variables listed in env_check are
149    also preserved in the env_reset case, provided that they do not
150    contain a '/' or '%' character.  Note that it is not necessary
151    to also list a variable in env_keep--having it in env_check is
152    sufficent.
153
154    The default lists of variables to be preserved and/or checked
155    are displayed when sudo is run by root with the -V flag.
156
157o Upgrading from a version prior to 1.6.8:
158
159    Prior to sudo 1.6.8, if /var/run did not exist, sudo would put
160    the time stamp files in /tmp/.odus.  As of sudo 1.6.8, the
161    time stamp files will be placed in /var/adm/sudo or /usr/adm/sudo
162    if there is no /var/run directory.  This directory will be
163    created if it does not already exist.
164
165    Previously, a sudoers entry that explicitly prohibited running
166    a command as a certain user did not override a previous entry
167    allowing the same command.  This has been fixed in sudo 1.6.8
168    such that the last match is now used (as it is documented).
169    Hopefully no one was depending on the previous (buggy) beghavior.
170
171o Upgrading from a version prior to 1.6:
172
173    As of sudo 1.6, parsing of runas entries and the NOPASSWD tag
174    has changed.  Prior to 1.6, a runas specifier applied only to
175    a single command directly following it.  Likewise, the NOPASSWD
176    tag only allowed the command directly following it to be run
177    without a password.  Starting with sudo 1.6, both the runas
178    specifier and the NOPASSWD tag are "sticky" for an entire
179    command list.  So, given the following line in sudo < 1.6
180
181	millert ALL=(daemon) NOPASSWD:/usr/bin/whoami,/bin/ls
182
183    millert would be able to run /usr/bin/whoami as user daemon
184    without a password and /bin/ls as root with a password.
185
186    As of sudo 1.6, the same line now means that millert is able
187    to run run both /usr/bin/whoami and /bin/ls as user daemon
188    without a password.  To expand on this, take the following
189    example:
190
191	millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, (root) /bin/ls, \
192	    /sbin/dump
193
194    millert can run /usr/bin/whoami as daemon and /bin/ls and
195    /sbin/dump as root.  No password need be given for either
196    command.  In other words, the "(root)" sets the default runas
197    user to root for the rest of the list.  If we wanted to require
198    a password for /bin/ls and /sbin/dump the line could be written
199    thusly:
200
201	millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, \
202	    (root) PASSWD:/bin/ls, /sbin/dump
203
204    Additionally, sudo now uses a per-user time stamp directory
205    instead of a time stamp file.  This allows tty time stamps to
206    simply be files within the user's time stamp dir.  For the
207    default, non-tty case, the time stamp on the directory itself
208    is used.
209
210    Also, the temporary file used by visudo is now /etc/sudoers.tmp
211    since some versions of vipw on systems with shadow passwords use
212    /etc/stmp for the temporary shadow file.
213
214o Upgrading from a version prior to 1.5:
215
216    By default, sudo expects the sudoers file to be mode 0440 and
217    to be owned by user and group 0.  This differs from version 1.4
218    and below which expected the sudoers file to be mode 0400 and
219    to be owned by root.  Doing a `make install' will set the sudoers
220    file to the new mode and group.  If sudo encounters a sudoers
221    file with the old permissions it will attempt to update it to
222    the new scheme.  You cannot, however, use a sudoers file with
223    the new permissions with an old sudo binary.  It is suggested
224    that if have a means of distributing sudo you distribute the
225    new binaries first, then the new sudoers file (or you can leave
226    sudoers as is and sudo will fix the permissions itself as long
227    as sudoers is on a local file system).
228