406 lines
18 KiB
Plaintext
406 lines
18 KiB
Plaintext
Notes on upgrading from an older release
|
|
========================================
|
|
|
|
o Upgrading from a version prior to 1.8.16:
|
|
|
|
When editing files with sudoedit, files in a directory that is
|
|
writable by the invoking user may no longer be edited by default.
|
|
Also, sudoedit will refuse to follow a symbolic link in the
|
|
path to be edited if that directory containing the link is
|
|
writable by the user. This behavior can be disabled by negating
|
|
the sudoedit_checkdir sudoers option, which is now enabled by
|
|
default.
|
|
|
|
o Upgrading from a version prior to 1.8.15:
|
|
|
|
Prior to version 1.8.15, when env_reset was enabled (the default)
|
|
and the -s option was not used, the SHELL environment variable
|
|
was set to the shell of the invoking user. In 1.8.15 and above,
|
|
when env_reset is enabled and the -s option is not used, SHELL
|
|
is set based on the target user.
|
|
|
|
When editing files with sudoedit, symbolic links will no longer
|
|
be followed by default. The old behavior can be restored by
|
|
enabling the sudoedit_follow option in sudoers or on a per-command
|
|
basis with the FOLLOW and NOFOLLOW tags.
|
|
|
|
Prior to version 1.8.15, groups listed in sudoers that were not
|
|
found in the system group database were passed to the group
|
|
plugin, if any. Starting with 1.8.15, only groups of the form
|
|
%:group are resolved via the group plugin by default. The old
|
|
behavior can be restored by using the always_query_group_plugin
|
|
sudoers option.
|
|
|
|
Locking of the time stamp file has changed in sudo 1.8.15.
|
|
Previously, the user's entire time stamp file was locked while
|
|
retrieving and updating a time stamp record. Now, only a single
|
|
record, specific to the tty or parent process ID, is locked.
|
|
This lock is held while the user enters their password. If
|
|
sudo is suspended at the password prompt (or run in the
|
|
background), the lock is dropped until sudo is resumed, at which
|
|
point it will be reacquired. This allows sudo to be used in a
|
|
pipeline even when a password is required--only one instance
|
|
of sudo will prompt for a password.
|
|
|
|
o Upgrading from a version prior to 1.8.14:
|
|
|
|
On HP-UX, sudo will no longer check for "plugin.sl" if "plugin.so"
|
|
is specified but does not exist. This was a temporary hack for
|
|
backwards compatibility with Sudo 1.8.6 and below when the
|
|
plugin path name was not listed in sudo.conf. A plugin path
|
|
name that explicitly ends in ".sl" will still work as expected.
|
|
|
|
o Upgrading from a version prior to 1.8.12:
|
|
|
|
On Solaris, sudo is now able to determine the NIS domain name.
|
|
As a result, if you had previously been using netgroups that
|
|
do not include the domain, you will need to either set the
|
|
domain in the entry or leave the domain part of the tuple blank.
|
|
|
|
For example, the following will no longer work:
|
|
my-hosts (foo,-,-) (bar,-,-) (baz,-,-)
|
|
and should be changed to:
|
|
my-hosts (foo,-,) (bar,-,) (baz,-,)
|
|
|
|
o Upgrading from a version prior to 1.8.10:
|
|
|
|
The time stamp file format has changed in sudo 1.8.10. There
|
|
is now a single time stamp file for each user, even when tty-based
|
|
time stamps are used. Each time stamp file may contain multiple
|
|
records to support tty-based time stamps as well as multiple
|
|
authentication users. On systems that support it, monotonic
|
|
time is stored instead of wall clock time. As a result, it is
|
|
important that the time stamp files not persist when the system
|
|
reboots. For this reason, the default location for the time
|
|
stamp files has changed back to a directory located in /var/run.
|
|
Systems that do not have /var/run (e.g. AIX) or that do not clear
|
|
it on boot (e.g. HP-UX) will need to clear the time stamp
|
|
directory via a start up script. Such a script is installed by
|
|
default on AIX and HP-UX systems.
|
|
|
|
Because there is now a single time stamp file per user, the -K
|
|
option will remove all of the user's time stamps, not just the
|
|
time stamp for the current terminal.
|
|
|
|
Lecture status is now stored separately from the time stamps
|
|
in a separate directory: /var/db/sudo/lectured, /var/lib/sudo/lectured
|
|
or /var/adm/sudo/lectured depending on what is present on the
|
|
system.
|
|
|
|
LDAP-based sudoers now uses a default search filter of
|
|
(objectClass=sudoRole) for more efficient queries. It is
|
|
possible to disable the default search filter by specifying
|
|
SUDOERS_SEARCH_FILTER in ldap.conf but omitting a value.
|
|
|
|
o Upgrading from a version prior to 1.8.7:
|
|
|
|
Sudo now stores its libexec files in a "sudo" sub-directory
|
|
instead of in libexec itself. For backwards compatibility, if
|
|
the plugin is not found in the default plugin directory, sudo
|
|
will check the parent directory default directory ends in "/sudo".
|
|
|
|
The default sudo plugins now all use the .so extension, regardless
|
|
of the extension used by native shared libraries. For backwards
|
|
compatibility, sudo on HP-UX will also search for a plugin with
|
|
an .sl extension if the .so version is not found.
|
|
|
|
Handling of users belonging to a large number of groups has
|
|
changed. Previously, sudo would only use the group list from
|
|
the kernel unless the system_group plugin was enabled in sudoers.
|
|
Now, sudo will query the groups database if the user belongs
|
|
to the maximum number of groups supported by the kernel. See
|
|
the group_source and max_groups settings in the sudo.conf manual
|
|
for details.
|
|
|
|
o Upgrading from a version prior to 1.8.2:
|
|
|
|
When matching Unix groups in the sudoers file, sudo will now
|
|
match based on the name of the group as it appears in sudoers
|
|
instead of the group ID. This can substantially reduce the
|
|
number of group lookups for sudoers files that contain a large
|
|
number of groups. There are a few side effects of this change.
|
|
|
|
1) Unix groups with different names but the same group ID are
|
|
can no longer be used interchangeably. Sudo will look up all
|
|
of a user's groups by group ID and use the resulting group
|
|
names when matching sudoers entries. If there are multiple
|
|
groups with the same ID, the group name returned by the
|
|
system getgrgid() library function is the name that will be
|
|
used when matching sudoers entries.
|
|
|
|
2) Unix group names specified in the sudoers file that are
|
|
longer than the system maximum will no longer match. For
|
|
instance, if there is a Unix group "fireflie" on a system
|
|
where group names are limited to eight characters, "%fireflies"
|
|
in sudoers will no longer match "fireflie". Previously, a
|
|
lookup by name of the group "fireflies" would have matched
|
|
the "fireflie" group on most systems.
|
|
|
|
The legacy group matching behavior may be restored by enabling
|
|
the match_group_by_gid Defaults option in sudoers available
|
|
in sudo 1.8.18 and higher.
|
|
|
|
o Upgrading from a version prior to 1.8.1:
|
|
|
|
Changes in the sudoers parser could result in parse errors for
|
|
existing sudoers file. These changes cause certain erroneous
|
|
entries to be flagged as errors where before they allowed.
|
|
Changes include:
|
|
|
|
Combining multiple Defaults entries with a backslash. E.g.
|
|
|
|
Defaults set_path \
|
|
Defaults syslog
|
|
|
|
which should be:
|
|
|
|
Defaults set_path
|
|
Defaults syslog
|
|
|
|
Also, double-quoted strings with a missing end-quote are now
|
|
detected and result in an error. Previously, text starting a
|
|
double quote and ending with a newline was ignored. E.g.
|
|
|
|
Defaults set_path"foo
|
|
|
|
In previous versions of sudo, the `"foo' portion would have
|
|
been ignored.
|
|
|
|
To avoid problems, sudo 1.8.1's "make install" will not install
|
|
a new sudo binary if the existing sudoers file has errors.
|
|
|
|
In Sudo 1.8.1 the "noexec" functionality has moved out of the
|
|
sudoers policy plugin and into the sudo front-end. As a result,
|
|
the path to the noexec file is now specified in the sudo.conf
|
|
file instead of the sudoers file. If you have a sudoers file
|
|
that uses the "noexec_file" option, you will need to move the
|
|
definition to the sudo.conf file instead.
|
|
|
|
Old style in /etc/sudoers:
|
|
Defaults noexec_file=/usr/local/libexec/sudo_noexec.so
|
|
|
|
New style in /etc/sudo.conf:
|
|
Path noexec /usr/local/libexec/sudo_noexec.so
|
|
|
|
o Upgrading from a version prior to 1.8.0:
|
|
|
|
Starting with version 1.8.0, sudo uses a modular framework to
|
|
support policy and I/O logging plugins. The default policy
|
|
plugin is "sudoers" which provides the traditional sudoers
|
|
evaluation and I/O logging. Plugins are typically located in
|
|
/usr/libexec or /usr/local/libexec, though this is system-dependent.
|
|
The sudoers plugin is named "sudoers.so" on most systems.
|
|
|
|
The sudo.conf file, usually stored in /etc, is used to configure
|
|
plugins. This file is optional--if no plugins are specified
|
|
in sudo.conf, the "sudoers" plugin is used. See the example
|
|
sudo.conf file in the doc directory or refer to the updated
|
|
sudo manual to see how to configure sudo.conf.
|
|
|
|
The "askpass" setting has moved from the sudoers file to the
|
|
sudo.conf file. If you have a sudoers file that uses the
|
|
"askpass" option, you will need to move the definition to the
|
|
sudo.conf file.
|
|
|
|
Old style in /etc/sudoers:
|
|
Defaults askpass=/usr/X11R6/bin/ssh-askpass
|
|
|
|
New style in /etc/sudo.conf:
|
|
Path askpass /usr/X11R6/bin/ssh-askpass
|
|
|
|
o Upgrading from a version prior to 1.7.5:
|
|
|
|
Sudo 1.7.5 includes an updated LDAP schema with support for
|
|
the sudoNotBefore, sudoNotAfter and sudoOrder attributes.
|
|
|
|
The sudoNotBefore and sudoNotAfter attribute support is only
|
|
used when the SUDOERS_TIMED setting is enabled in ldap.conf.
|
|
If enabled, those attributes are used directly when constructing
|
|
an LDAP filter. As a result, your LDAP server must have the
|
|
updated schema if you want to use sudoNotBefore and sudoNotAfter.
|
|
|
|
The sudoOrder support does not affect the LDAP filter sudo
|
|
constructs and so there is no need to explicitly enable it in
|
|
ldap.conf. If the sudoOrder attribute is not present in an
|
|
entry, a value of 0 is used. If no entries contain sudoOrder
|
|
attributes, the results are in whatever order the LDAP server
|
|
returns them, as in past versions of sudo.
|
|
|
|
Older versions of sudo will simply ignore the new attributes
|
|
if they are present in an entry. There are no compatibility
|
|
problems using the updated schema with older versions of sudo.
|
|
|
|
o Upgrading from a version prior to 1.7.4:
|
|
|
|
Starting with sudo 1.7.4, the time stamp files have moved from
|
|
/var/run/sudo to either /var/db/sudo, /var/lib/sudo or /var/adm/sudo.
|
|
The directories are checked for existence in that order. This
|
|
prevents users from receiving the sudo lecture every time the
|
|
system reboots. Time stamp files older than the boot time are
|
|
ignored on systems where it is possible to determine this.
|
|
|
|
Additionally, the tty_tickets sudoers option is now enabled by
|
|
default. To restore the old behavior (single time stamp per user),
|
|
add a line like:
|
|
Defaults !tty_tickets
|
|
to sudoers or use the --without-tty-tickets configure option.
|
|
|
|
The HOME and MAIL environment variables are now reset based on the
|
|
target user's password database entry when the env_reset sudoers option
|
|
is enabled (which is the case in the default configuration). Users
|
|
wishing to preserve the original values should use a sudoers entry like:
|
|
Defaults env_keep += HOME
|
|
to preserve the old value of HOME and
|
|
Defaults env_keep += MAIL
|
|
to preserve the old value of MAIL.
|
|
|
|
NOTE: preserving HOME has security implications since many programs
|
|
use it when searching for configuration files. Adding HOME to env_keep
|
|
may enable a user to run unrestricted commands via sudo.
|
|
|
|
The default syslog facility has changed from "local2" to "authpriv"
|
|
(or "auth" if the operating system doesn't have "authpriv").
|
|
The --with-logfac configure option can be used to change this
|
|
or it can be changed in the sudoers file.
|
|
|
|
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 sea ch 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 NEWS 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 environment 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
|
|
sufficient.
|
|
|
|
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 time stamp files in /tmp/.odus. As of sudo 1.6.8, the
|
|
time stamp 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) behavior.
|
|
|
|
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
|
|
as:
|
|
|
|
millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, \
|
|
(root) PASSWD:/bin/ls, /sbin/dump
|
|
|
|
Additionally, sudo now uses a per-user time stamp directory
|
|
instead of a time stamp file. This allows tty time stamps to
|
|
simply be files within the user's time stamp dir. For the
|
|
default, non-tty case, the time stamp 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).
|