Rework source layout in preparation for modular sudo.
This commit is contained in:
Todd C. Miller
143
doc/UPGRADE
Normal file
143
doc/UPGRADE
Normal file
@@ -0,0 +1,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).
|
||||
Reference in New Issue
Block a user