[BACK]Return to UPGRADE CVS log [TXT][DIR] Up to [local] / src / usr.bin / sudo

Annotation of src/usr.bin/sudo/UPGRADE, Revision 1.1.1.1

1.1       millert     1: Notes on upgrading from an older release
                      2: ========================================
                      3:
                      4: o Upgrading from a version prior to 1.6:
                      5:
                      6:     As of sudo 1.6, parsing of runas entries and the NOPASSWD tag
                      7:     has changed.  Prior to 1.6, a runas specifier applied only to
                      8:     a single command directly following it.  Likewise, the NOPASSWD
                      9:     tag only allowed the command directly following it to be run
                     10:     without a password.  Starting with sudo 1.6, both the runas
                     11:     specifier and the NOPASSWD tag are "sticky" for an entire
                     12:     command list.  So, given the following line in sudo < 1.6
                     13:
                     14:        millert ALL=(daemon) NOPASSWD:/usr/bin/whoami,/bin/ls
                     15:
                     16:     millert would be able to run /usr/bin/whoami as user daemon
                     17:     without a password and /bin/ls as root with a password.
                     18:
                     19:     As of sudo 1.6, the same line now means that millert is able
                     20:     to run run both /usr/bin/whoami and /bin/ls as user daemon
                     21:     without a password.  To expand on this, take the following
                     22:     example:
                     23:
                     24:        millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, (root) /bin/ls, \
                     25:            /sbin/dump
                     26:
                     27:     millert can run /usr/bin/whoami as daemon and /bin/ls and
                     28:     /sbin/dump as root.  No password need be given for either
                     29:     command.  In other words, the "(root)" sets the default runas
                     30:     user to root for the rest of the list.  If we wanted to require
                     31:     a password for /bin/ls and /sbin/dump the line could be written
                     32:     thusly:
                     33:
                     34:        millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, \
                     35:            (root) PASSWD:/bin/ls, /sbin/dump
                     36:
                     37:     Additionally, sudo now uses a per-user timestamp directory
                     38:     instead of a timestamp file.  This allows tty timestamps to
                     39:     simply be files within the user's timestamp dir.  For the
                     40:     default, non-tty case, the timestamp on the directory itself
                     41:     is used.
                     42:
                     43:     Also, the temporary file used by visudo is now /etc/sudoers.tmp
                     44:     since some versions of vipw on systems with shadow passwords use
                     45:     /etc/stmp for the temporary shadow file.
                     46:
                     47: o Upgrading from a version prior to 1.5:
                     48:
                     49:     By default, sudo expects the sudoers file to be mode 0440 and
                     50:     to be owned by user and group 0.  This differs from version 1.4
                     51:     and below which expected the sudoers file to be mode 0400 and
                     52:     to be owned by root.  Doing a `make install' will set the sudoers
                     53:     file to the new mode and group.  If sudo encounters a sudoers
                     54:     file with the old permissions it will attempt to update it to
                     55:     the new scheme.  You cannot, however, use a sudoers file with
                     56:     the new permissions with an old sudo binary.  It is suggested
                     57:     that if have a means of distributing sudo you distribute the
                     58:     new binaries first, then the new sudoers file (or you can leave
                     59:     sudoers as is and sudo will fix the permissions itself as long
                     60:     as sudoers is on a local filesystem).