notes on updating from an earlier release

This commit is contained in:
Todd C. Miller
1999-04-08 23:56:13 +00:00
parent f1891c8796
commit 0ef9c81f16
3 changed files with 52 additions and 26 deletions

26
INSTALL
View File

@@ -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
===========================

View File

@@ -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 \

50
UPGRADE Normal file
View File

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