notes on updating from an earlier release

INSTALL

@@ -13,7 +13,7 @@ Simple sudo installation
 For most systems and configurations it is possible simply to:
 
     0) If you are upgrading from a previous version of sudo
-       please read the section "Notes on upgrading from an older release".
+       please read the info in the UPGRADE file before proceeding.
 
     1) If you previously ran `configure' on a different host
        you will probably want to do a `make distclean' to remove
@@ -55,30 +55,6 @@ For most systems and configurations it is possible simply to:
        site.  You will probably want to refer the sample.sudoers
        file and sudoers man page included with the sudo package.
 
-Notes on upgrading from an older release
-========================================
-
-Starting with sudo 1.5.7 the configuration method has changed
-significantly as compared to previous versions.  All options are
-now set via the configure script.  See below for a list of all the
-configure options and their meanings.
-
-As of sudo 1.6, parsing of runas entries and the NOPASSWD tag has
-changed.  Please read the UPGRADE file.
-
-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
-filesystem).
-
 Available configure options
 ===========================
 

Makefile.in

@@ -116,7 +116,7 @@ HDRS = sudo.h compat.h version.h insults.h \
 VERSION = 1.6
 
 DISTFILES = $(SRCS) $(HDRS) BUGS CHANGES COPYING HISTORY INSTALL \
-            INSTALL.configure TODO PORTING README RUNSON \
+            INSTALL.configure UPGRADE TODO PORTING README RUNSON \
             FAQ TROUBLESHOOTING Makefile.in acsite.m4 aixcrypt.exp \
             config.h.in configure configure.in config.guess config.sub \
             pathnames.h.in getcwd.c indent.pro install-sh \

UPGRADE

@@ -0,0 +1,50 @@
+Notes on upgrading from an older release
+========================================
+
+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 dfault 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
+
+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 filesystem).