notes on updating from an earlier release
This commit is contained in:
26
INSTALL
26
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
|
||||
===========================
|
||||
|
||||
|
@@ -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
50
UPGRADE
Normal 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).
|
Reference in New Issue
Block a user