1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
Notes on upgrading from an older release
========================================
o Upgrading from a version prior to 1.7.0:
Starting with sudo 1.7.0 comments in the sudoers file must not
have a digit or minus sign immediately after the comment character
('#'). Otherwise, the comment may be interpreted as a user or
group ID.
When sudo is build with LDAP support the /etc/nsswitch.conf file is
now used to determine the sudoers seach order. sudo will default to
only using /etc/sudoers unless /etc/nsswitch.conf says otherwise.
This can be changed with an nsswitch.conf line, e.g.:
sudoers: ldap files
Would case LDAP to be searched first, then the sudoers file.
To restore the pre-1.7.0 behavior, run configure with the
--with-nsswitch=no flag.
Sudo now ignores user .ldaprc files as well as system LDAP defaults.
All LDAP configuration is now in /etc/ldap.conf (or whichever file
was specified by configure's --with-ldap-conf-file option).
If you are using TLS, you may now need to specify:
tls_checkpeer no
in sudo's ldap.conf unless ldap.conf references a valid certificate
authority file(s).
Please also see the WHATSNEW file for a list of new features in
sudo 1.7.0.
o Upgrading from a version prior to 1.6.9:
Starting with sudo 1.6.9, if an OS supports a modular authentication
method such as PAM, it will be used by default by configure.
Environment variable handling has changed significantly in sudo
1.6.9. Prior to version 1.6.9, sudo would preserve the user's
environment, pruning out potentially dangerous variables.
Beginning with sudo 1.6.9, the envionment is reset to a default
set of values with only a small number of "safe" variables
preserved. To preserve specific environment variables, add
them to the "env_keep" list in sudoers. E.g.
Defaults env_keep += "EDITOR"
The old behavior can be restored by negating the "env_reset"
option in sudoers. E.g.
Defaults !env_reset
There have also been changes to how the "env_keep" and
"env_check" options behave.
Prior to sudo 1.6.9, the TERM and PATH environment variables
would always be preserved even if the env_keep option was
redefined. That is no longer the case. Consequently, if
env_keep is set with "=" and not simply appended to (i.e. using
"+="), PATH and TERM must be explicitly included in the list
of environment variables to keep. The LOGNAME, SHELL, USER,
and USERNAME environment variables are still always set.
Additionally, the env_check setting previously had no effect
when env_reset was set (which is now on by default). Starting
with sudo 1.6.9, environment variables listed in env_check are
also preserved in the env_reset case, provided that they do not
contain a '/' or '%' character. Note that it is not necessary
to also list a variable in env_keep--having it in env_check is
sufficent.
The default lists of variables to be preserved and/or checked
are displayed when sudo is run by root with the -V flag.
o Upgrading from a version prior to 1.6.8:
Prior to sudo 1.6.8, if /var/run did not exist, sudo would put
the timestamp files in /tmp/.odus. As of sudo 1.6.8, the
timestamp files will be placed in /var/adm/sudo or /usr/adm/sudo
if there is no /var/run directory. This directory will be
created if it does not already exist.
Previously, a sudoers entry that explicitly prohibited running
a command as a certain user did not override a previous entry
allowing the same command. This has been fixed in sudo 1.6.8
such that the last match is now used (as it is documented).
Hopefully no one was depending on the previous (buggy) beghavior.
o Upgrading from a version prior to 1.6:
As of sudo 1.6, parsing of runas entries and the NOPASSWD tag
has changed. Prior to 1.6, a runas specifier applied only to
a single command directly following it. Likewise, the NOPASSWD
tag only allowed the command directly following it to be run
without a password. Starting with sudo 1.6, both the runas
specifier and the NOPASSWD tag are "sticky" for an entire
command list. So, given the following line in sudo < 1.6
millert ALL=(daemon) NOPASSWD:/usr/bin/whoami,/bin/ls
millert would be able to run /usr/bin/whoami as user daemon
without a password and /bin/ls as root with a password.
As of sudo 1.6, the same line now means that millert is able
to run run both /usr/bin/whoami and /bin/ls as user daemon
without a password. To expand on this, take the following
example:
millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, (root) /bin/ls, \
/sbin/dump
millert can run /usr/bin/whoami as daemon and /bin/ls and
/sbin/dump as root. No password need be given for either
command. In other words, the "(root)" sets the default runas
user to root for the rest of the list. If we wanted to require
a password for /bin/ls and /sbin/dump the line could be written
thusly:
millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, \
(root) PASSWD:/bin/ls, /sbin/dump
Additionally, sudo now uses a per-user timestamp directory
instead of a timestamp file. This allows tty timestamps to
simply be files within the user's timestamp dir. For the
default, non-tty case, the timestamp on the directory itself
is used.
Also, the temporary file used by visudo is now /etc/sudoers.tmp
since some versions of vipw on systems with shadow passwords use
/etc/stmp for the temporary shadow file.
o Upgrading from a version prior to 1.5:
By default, sudo expects the sudoers file to be mode 0440 and
to be owned by user and group 0. This differs from version 1.4
and below which expected the sudoers file to be mode 0400 and
to be owned by root. Doing a `make install' will set the sudoers
file to the new mode and group. If sudo encounters a sudoers
file with the old permissions it will attempt to update it to
the new scheme. You cannot, however, use a sudoers file with
the new permissions with an old sudo binary. It is suggested
that if have a means of distributing sudo you distribute the
new binaries first, then the new sudoers file (or you can leave
sudoers as is and sudo will fix the permissions itself as long
as sudoers is on a local file system).
|
