isa/sudo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

rewrote for sudo 1.3.6

Browse Source
This commit is contained in:
Todd C. Miller
1995-11-26 02:23:46 +00:00
parent c4e077ce01
commit c68baecaf1
1 changed files with 185 additions and 87 deletions
Download Patch File Download Diff File Expand all files Collapse all files

270
INSTALL
View File

@@ -1,109 +1,207 @@
INSTALL NOTES Installation instructions for CU sudo 1.3.6
===========================================
0) Run the configure script, ie: "./configure". See the SUPPORTED file Sudo uses a `configure' script to probe the capabilities and type
for a list of OS's sudo is known to work on. Configure will generate of the system in question. Please read this document fully before
config.h, pathnames.h, Makefile and visudoers/Makefile. You shouldn't configuring and building sudo.
need to hand-edit the Makefiles but if you don't like configure's choice
of C compiler, yacc or lex programs you may want to. You can also
use the --prefix flag to configure to install sudo/visudo in a place
other than /usr/local (ie: --prefix=/opt).
BEWARE: configure caches values in config.cache. This will cause Simple sudo installation
problems if you are building for different architectures. You ========================
*must* do a "make realclean" to remove the configure-generated
files betweem builds in this case. Basically, you should do a
"make realclean" before you run configure each time.
NOTE: if you use shadow passwords or C2 security you need to use the For most systems and configurations it is possible simply to:
--with-C2 flag to configure. Currently this only works for SunOS 4.x,
hpux 9.x, ultrix 4.x, Digital UNIX (aka DEC OSF1), Irix 5.x and
ConvexOS with C2 security. For hpux only, you can use
--with-C2 if you are expecting to migrate to C2 security later but it
makes password lookups about twice as slow.
NOTE2: if you use AFS, you need to run configure with --with-AFS 0) If you previously ran `configure' on a different host
you will probably want to do a `make clean' to remove
the old `config.cache' file. Otherwise, `configure'
will use the cached values which is probably not
what you want unless the two hosts are running the
same OS and are virtually identical. Alternately,
one can simply `rm config.cache'.
NOTE3: if you use DCE integrated login services (ie, the DCE security 1) Read the `OS dependent notes' section for any particular
daemon), then you need to run configure with --with-DCE. The DCE "gotchas" relating to your operating system.
configuration option is presently known to work on HP-UX 10.0 and
HP-UX 9.X systems, where sudo is built with either gcc 2.7.0 or HP's
ANSI C compiler. To get the DCE version to compile on other platforms,
you will probably have to fiddle with the configure file and/or the
source code.
NOTE4: if you use kerberos version 4 you need to run configure 2) `cd' to the source or build directory and type `./configure'
with --with-kerb4. This has only been tested with the Cygnus to generate a Makefile and config.h file suitable for
kerberos package (CNS) but should work for vanilla kerberos too. building sudo. Before you actually run configure you
If you use kerberos version 5 you need to run configure with --with-kerb5. should read the `Available configure options' section
This enables the same code as --with-kerb4 but also adds in the to see if there are any special options you may want
kerb4 compatibility libraries. Kerb5 support is currently untested, or need. Also of interest may be the section on
please let us know if it work for you. `Mixing password authentication schemes'.
NOTE5: Solaries users beware, you need to make sure that the 3) Edit the configure-generated Makefile if you wish to
"real" (ie: non-ucb) cc is in your path (unless you use gcc). change any of the default paths (alternately you could
Sudo is designed to compile with the standard C compiler and have changed the paths via options to `configure'.
will not build correctly with /usr/ucb/cc.
1) Read the OPTIONS file and then edit options.h to enable/disable the 4) Edit `options.h' to enable any particular non-default
options you may or may not want. You should not have to edit options you wish to use. Refer to the OPTIONS file for
sudo.h or config.h. an explanation of each one. If you are building in
a separate build directory you may make a local copy
of options.h in that directory and edit it instead.
2) Type make. If configure did its job correctly there won't be any 5) Type `make' to compile sudo. If you are building sudo
problems. If this doesn't work, take a look at the file PORTING for in a separate build tree (apart from the sudo source)
tips on what might have gone wrong. Please mail us if you have a GNU make will probably be required. If `configure' did
its job properly (and you have a supported configuration)
there won't be any problems. If this doesn't work, take
a look at the files TROUBLESHOOTING and PORTING for tips
on what might have gone wrong. Please mail us if you have a
fix or if you are unable to come up with a fix (address at EOF). fix or if you are unable to come up with a fix (address at EOF).
3) Do a make install (as root) to install sudo. If you get an error 6) Type `make install' (as root) to install sudo, visudo, the
about setuid(0) failing, something went wrong with the install and man pages, and a skeleton sudoers file. Note that the install
the permissions on sudo are wrong. Sudo needs to run setuid root. will not overwrite an existing sudoers file. You can also
If you get this message, chances are it's not running setuid root. install various pieces the package via the install-binaries,
install-man, and install-sudoers make targets.
You can also install various pieces the package via install-binaries, 7) Edit the sudoers file with `visudo' as necessary for your
install-man, install-sudoers. site. You will probably want to refer the sample.sudoers
file and sudoers man page included with the sudo package.
4) Customize /etc/sudoers for your site. Read the man page and take a Available configure options
look at sample.sudoers to see how to do this. ===========================
5) You're done. This section describes flags accepted by the sudo's `configure' script.
Defaults are listed in brackets after the description.
A few notes: Configuration:
--cache-file=FILE Cache test results in FILE
a) To use syslog with the ultrix version you may want to grab --help Print the usage/help info
and install pub/DEC/jtkohl-syslog-complete.tar.Z available from
gatekeeper.dec.com via anonymous ftp. If you don't I'd suggest
logging to a separate file rather than using the 4.2BSD syslog()
that comes with ultrix. The jtkohl syslog is a nice port of the
4.3 syslogd that is backwards compatible with the ultrix version.
I recommend it highly.
b) visudo will *NOT* use the editor referred to by the EDITOR or --no-create Do not create output files
VISUAL environmental variables unless you define ENV_EDITOR in
sudo.h. I like the feature, but it can be a security hole
if you don't know about it. If you have EDITOR set to something
secure (ie: no shells or external commands) in the Makefile or
sudo.h you don't want to define ENV_EDITOR. Note that vi (the default
editor) is anything *but* secure in this respect (and no, setting the
editor to a wrapper that sets the SHELL envar to /bin/true does *not*
make vi secure--you can change your shell from within vi). If you
leave the default of vi, you really don't stand to lose anything by
defining ENV_EDITOR.
c) If you have a sense of humor you may want to define USE_INSULTS to --quiet, --silent Do not print `checking...' messages
get the insults from the "old" sudo when you enter an incorrect
password. Beware, this feature causes some people to want to throw
their machine across the room and dash it to tiny pieces.
Sci fi fans may want to define HAL as well (see insults.h).
d) If you are *not* running sendmail or some other mailer, you should Directory and file names:
comment out the MAILER #define in sudo.h. --prefix=PREFIX Install architecture-independent files in PREFIX
This really only applies to man pages.
[/usr/local]
e) If you are running AIX and sudo says that it cannot find a user --exec-prefix=EPREFIX Install architecture-dependent files in EPREFIX
that is clearly listed in the sudoers file try compiling with This includes the sudo and visudo executables.
optimization turned off. The AIX C compiler produces incorrect [same as prefix]
code with the -O flag on some versions of AIX. In fact, I've
run into some nasty bugs in the C compiler on an AIX 3.2.x box --bindir=DIR Install `sudo' in DIR [EPREFIX/bin]
that just produced incorrect code, even without opitmization.
Morale of the story, use gcc if you can... --sbindir=DIR Install `visudo' in DIR
[EPREFIX/etc for historical reasons]
--sysconfdir=DIR Install `sudoers' file in DIR [/etc]
--mandir=DIR Install man pages in DIR [PREFIX/man]
--srcdir=DIR Find the sources in DIR [configure dir or ..]
Special features/options:
--with-getpass Use system getpass(3) instead of sudo-supplied
tgetpass() for systems where tgetpass() fails.
--with-C2 Enable C2 security (shadow password) support
See `Shadow password and C2 support' section
for a list of supported platforms.
--with-skey Enable S/Key support.
--with-SecurID Enable SecurID support.
--with-kerb4 Enable kerberos v4 support
Tested only with the Cygnus Network Security
package (CNS).
--with-kerb5 Enable kerberos v5 support.
This enables with kerberos v4 support and
links with the standard kerberos v5 libraries
as well as the v4 compatibility libraries.
--with-AFS Enable AFS support.
Written for AFS under AIX 3.2.x but should
work for AFS on most platforms.
--with-DCE Enable DCE support.
Known to work on HP-UX 9.X and 10.0.
Other platforms may require source code
and/or `configure' changes.
--with-csops Add CSOps standard options.
Shadow password and C2 support
==============================
Shadow passwords (also included with most C2 security packages)
are supported on most major platforms for which they exist.
The `configure' script will attempt to determine if your
system uses shadow passwords, but this is really just a guess.
Therefore, it is suggested that you use the `--with-C2' option
to `configure' if you need shadow password support.
Shadow passwords are supported on the following platforms:
SunOS 4.x
Solaris 2.x
HP-UX 9.x
Ultrix 4.x
Digital UNIX 3.x
Irix 5.x
AIX 3.2.x
ConvexOS with C2 security
Linux
SCO 3.2.2
SVR4 (and variants using standard SVR4 shadow passwords)
It is possible to configure in shadow password support even
if your system does not currently use shadow passwords.
That way, if you put shadow passwords in place, your installed
sudo will already support them.
Mixing password authentication schemes
======================================
It is possible to build sudo with support for several authentication
schemes, including shadow passwords, kerberos, s/key, AFS, DCE,
and normal UN*X passwords into a single binary. User validation
will take slightly longer, of course, but it may be valuable
to have a single sudo binary that is distributed among systems
with varying authentication mechanisms.
OS dependent notes
==================
Solaris 2.x:
You need to have a C compiler in order to build sudo.
Since Solaris 2.x does not come with one by default this
means that you either need to have purchased the unbundled Sun
C compiler or have a copy of the GNU C compiler (gcc).
Sparc binaries for gcc may be gotten via the URL
ftp://prep.ai.mit.edu/pub/gnu/sparc-sun-solaris2
NOTE: sudo will not build with the sun C compiler in BSD
compatibility mode (/usr/ucb/cc). Sudo is designed
to compile with the standard C compiler (or gcc) and
will not build correctly with /usr/ucb/cc.
AIX 3.2.x:
I've had various problems with the AIX C compiler producing
incorrect code when the -O flag was used. When optimization
is not used, the problems go away. Gcc does not appear
to have this problem.
Also, the AIX 3.2.x lex will not work with sudo's parse.lex.
This should not be a problem as sudo comes shipped with
a pre-generated lex.yy.c (created by flex). If you want
to modify the lex tokenizer, make sure you grab a copy of
flex from ftp.ee.lbl.gov (also available on most GNU mirrors)
and sudo will use that instead.
Ultrix 4.x:
Ultrix still ships with the 4.2BSD syslog(3) which does not
allow things like logging different faclities to different
files, redirecting logs to a single loghost and other niceties.
You may want to just grab and install:
ftp://gatekeeper.dec.com/pub/DEC/jtkohl-syslog-complete.tar.Z
(available via anonymous ftp) which is a port if the 4.3BSD
syslog/syslogd that is backwards compatible with the Ultrix version.
I recommend it highly. If you do not do this you probably want
to set `LOGGING' to SLOG_FILE in options.h.
Please send changes, bugs, security holes, and gripes to: Please send changes, bugs, security holes, and gripes to:
sudo-bugs@cs.colorado.edu sudo-bugs@cs.colorado.edu