Return to UPGRADE CVS log

Up to [local] / src / usr.bin / sudo

Annotation of src/usr.bin/sudo/UPGRADE, Revision 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).