~ubuntu-branches/ubuntu/oneiric/sudo/oneiric-updates

Notes on upgrading from an older release

========================================

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 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 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 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 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 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) 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 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).