diff --git a/INSTALL b/INSTALL index 8091add5b..d4aac0d38 100644 --- a/INSTALL +++ b/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 =========================== diff --git a/Makefile.in b/Makefile.in index c2567ecc1..761ab3ab4 100644 --- a/Makefile.in +++ b/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 \ diff --git a/UPGRADE b/UPGRADE new file mode 100644 index 000000000..1b15c0547 --- /dev/null +++ b/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).