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

Convert README and docs files to markdown.

Browse Source 
This makes things look better on GitHub and we can use the
markdown version directly in the new sudo web site.
This commit is contained in:
Todd C. Miller
2021-12-05 21:02:04 -07:00
parent 2c754a8d49
commit 3bd572ba80
19 changed files with 2493 additions and 2399 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1025
INSTALL
View File

File diff suppressed because it is too large Load Diff

1025
INSTALL.md Normal file
View File

File diff suppressed because it is too large Load Diff

16
MANIFEST
View File

@@ -1,12 +1,12 @@
ABOUT-NLS
ChangeLog
INSTALL
INSTALL.md
INSTALL.configure
MANIFEST
Makefile.in
NEWS
README
README.LDAP
README.md
README.LDAP.md
aclocal.m4
autogen.sh
config.h.in
@@ -21,13 +21,13 @@ docker/ubuntu/devel/Dockerfile
docker/ubuntu/latest/Dockerfile
docker/ubuntu/rolling/Dockerfile
docs/CONTRIBUTING.md
docs/CONTRIBUTORS
docs/HISTORY
docs/LICENSE
docs/CONTRIBUTORS.md
docs/HISTORY.md
docs/LICENSE.md
docs/Makefile.in
docs/SECURITY.md
docs/TROUBLESHOOTING
docs/UPGRADE
docs/TROUBLESHOOTING.md
docs/UPGRADE.md
docs/cvtsudoers.man.in
docs/cvtsudoers.mdoc.in
docs/fixman.sh

84
README
View File

@@ -1,84 +0,0 @@
The sudo philosophy
===================
Sudo is a program designed to allow a sysadmin to give limited root privileges
to users and log root activity. The basic philosophy is to give as few
privileges as possible but still allow people to get their work done.
Where to find sudo
==================
Before you try and build sudo, *please* make sure you have the current
version. The latest sudo may always be gotten via anonymous ftp from
ftp.sudo.ws in the directory /pub/sudo/ or from the sudo web site,
https://www.sudo.ws/
The distribution is sudo-M.m.tar.gz where `M' is the major version
number and `m' is the minor version number. BETA versions of sudo may
also be available. If you join the `sudo-workers' mailing list you
will get the BETA announcements (see the `Mailing lists' section below).
What's new
==========
See the NEWS file for a list of major changes in this release.
For a complete list of changes, see the ChangeLog file. For a
summary of major changes to the current stable release, see the web
page, https://www.sudo.ws/stable.html.
If you are upgrading from an earlier version of Sudo, please see
the UPGRADE file in the docs directory.
For a history of sudo please see the HISTORY file in the docs directory.
You can find a list of contributors to sudo in the docs/CONTRIBUTORS file.
Building the release
====================
Please read the installation guide in the `INSTALL' file before trying to
build sudo. Pay special attention to the "OS dependent notes" section.
Copyright
=========
Sudo is distributed under an ISC-style license.
Please refer to the `LICENSE' file included with the release for details.
Mailing lists
=============
sudo-announce This list receives announcements whenever a new version
of sudo is released.
https://www.sudo.ws/mailman/listinfo/sudo-announce
sudo-blog This list receives a message when a new sudo blog
article is available.
https://www.sudo.ws/mailman/listinfo/sudo-blog
sudo-commits This list receives a message for each commit made to
the sudo source repository.
https://www.sudo.ws/mailman/listinfo/sudo-commits
sudo-users This list is for questions and general discussion about sudo.
https://www.sudo.ws/mailman/listinfo/sudo-users
sudo-workers This list is for people working on and porting sudo.
https://www.sudo.ws/mailman/listinfo/sudo-workers
To subscribe to a list, visit its url (as listed above) and enter
your email address to subscribe. Digest versions are available but
these are fairly low traffic lists so the digest versions are not
a significant win.
Mailing list archives are also available. See the mailing list web sites
for the appropriate links.
Web page
========
There is a sudo web page at https://www.sudo.ws/ that contains an
overview of sudo, documentation, downloads, a bug tracker, information
about beta versions and other useful info.
Bug reports
===========
If you have found what you believe to be a bug, you can file a bug
report in the sudo bug database, on the web at https://bugzilla.sudo.ws/.
Please read over the `TROUBLESHOOTING' file in the docs directory *before*
submitting a bug report. When reporting bugs, please be sure to include
the version of sudo you are using as well as the platform you are running
it on.

55
README.LDAP → README.LDAP.md
View File

@@ -11,6 +11,7 @@ non LDAP-enabled build.
LDAP philosophy
===============
As times change and servers become cheap, an enterprise can easily have 500+
UNIX servers. Using LDAP to synchronize Users, Groups, Hosts, Mounts, and
others across an enterprise can greatly reduce the administrative overhead.
@@ -27,6 +28,7 @@ For information on OpenLDAP, please see http://www.openldap.org/.
Definitions
===========
Many times the word 'Directory' is used in the document to refer to the LDAP
server, structure and contents.
@@ -35,8 +37,9 @@ They are one and the same.
Build instructions
==================
The simplest way to build sudo with LDAP support is to include the
'--with-ldap' option.
`--with-ldap` option.
$ ./configure --with-ldap
@@ -49,11 +52,12 @@ Sudo is developed using OpenLDAP but Netscape-based LDAP libraries
(such as those present in Solaris) are also known to work.
Your mileage may vary. Please let the sudo workers mailing list
<sudo-workers@sudo.ws> know if special configuration was required
sudo-workers@sudo.ws know if special configuration was required
to build an LDAP-enabled sudo so we can improve sudo.
Schema Changes
==============
You must add the appropriate schema to your LDAP server before it
can store sudoers content.
@@ -61,13 +65,13 @@ For OpenLDAP, there are two options, depending on how slapd is configured.
The first option is to copy the file schema.OpenLDAP to the schema
directory (e.g. /etc/openldap/schema). You must then edit your
slapd.conf and add an include line the new schema, e.g.
slapd.conf and add an include line the new schema, for example:
# Sudo LDAP schema
include /etc/openldap/schema/sudo.schema
In order for sudoRole LDAP queries to be efficient, the server must index
the attribute 'sudoUser', e.g.
the attribute 'sudoUser', for example:
# Indices to maintain
index sudoUser eq
@@ -93,7 +97,7 @@ There is no need to restart slapd when updating on-line configuration.
For Netscape-derived LDAP servers such as SunONE, iPlanet or Fedora Directory,
copy the schema.iPlanet file to the schema directory with the name 99sudo.ldif.
On Solaris, schemas are stored in /var/Sun/mps/slapd-`hostname`/config/schema/.
On Solaris, schemas are stored in /var/Sun/mps/slapd-\`hostname\`/config/schema/.
For Fedora Directory Server, they are stored in /etc/dirsrv/schema/.
After copying the schema file to the appropriate directory, restart
@@ -112,57 +116,63 @@ to your Windows domain controller and run the following command:
Importing /etc/sudoers into LDAP
================================
Importing sudoers is a two-step process.
Step 1:
Ask your LDAP Administrator where to create the ou=SUDOers container.
For instance, if using OpenLDAP:
1. Ask your LDAP Administrator where to create the ou=SUDOers container.
For instance, if using OpenLDAP:
```
dn: ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: SUDOers
```
(An example location is shown below). Then use the cvtsudoers utility to
convert your sudoers file into LDIF format.
```
# SUDOERS_BASE=ou=SUDOers,dc=example,dc=com
# export SUDOERS_BASE
# cvtsudoers -f ldif -o /tmp/sudoers.ldif /etc/sudoers
```
Step 2:
Import into your directory server. The following example is for
OpenLDAP. If you are using another directory, provide the LDIF
file to your LDAP Administrator.
2. Import into your directory server. The following example is for
OpenLDAP. If you are using another directory, provide the LDIF
file to your LDAP Administrator.
```
# ldapadd -f /tmp/sudoers.ldif -H ldap://ldapserver \
-D cn=Manager,dc=example,dc=com -W -x
```
Step 3:
Verify the sudoers LDAP data:
3. Verify the sudoers LDAP data:
```
# ldapsearch -b "$SUDOERS_BASE" -D cn=Manager,dc=example,dc=com -W -x
```
Managing LDAP entries
=====================
Doing a one-time bulk load of your ldap entries is fine. However what if you
need to make minor changes on a daily basis? It doesn't make sense to delete
and re-add objects. (You can, but this is tedious).
I recommend using any of the following LDAP browsers to administer your SUDOers.
* GQ - The gentleman's LDAP client - Open Source - I use this a lot on Linux
and since it is Schema aware, I don't need to create a sudoRole template.
http://sourceforge.net/projects/gqclient/
* phpQLAdmin - Open Source - phpQLAdmin is an administration tool,
originally for QmailLDAP, that supports editing sudoRole objects
in version 2.3.2 and higher.
http://phpqladmin.com/
* LDAP Browser/Editor - by Jarek Gawor - I use this a lot on Windows
and Solaris. It runs anywhere in a Java Virtual Machine including
web pages. You have to make a template from an existing sudoRole entry.
http://www.iit.edu/~gawojar/ldap
http://www.mcs.anl.gov/~gawor/ldap
http://ldapmanager.com
@@ -170,16 +180,18 @@ I recommend using any of the following LDAP browsers to administer your SUDOers.
* Apache Directory Studio - Open Source - an Eclipse-based LDAP
development platform. Includes an LDAP browser, and LDIF editor,
a schema editor and more.
http://directory.apache.org/studio
There are dozens of others, some Open Source, some free, some not.
Configure your /etc/ldap.conf and /etc/nsswitch.conf
====================================================
The /etc/ldap.conf file is meant to be shared between sudo, pam_ldap, nss_ldap
and other ldap applications and modules. IBM Secureway unfortunately uses
the same file name but has a different syntax. If you need to change where
this file is stored, re-run configure with the --with-ldap-conf-file=PATH
this file is stored, re-run configure with the `--with-ldap-conf-file=PATH`
option.
See the "Configuring ldap.conf" section in the sudoers.ldap manual
@@ -192,12 +204,13 @@ After configuring /etc/ldap.conf, you must add a line in /etc/nsswitch.conf
to tell sudo to look in LDAP for sudoers. See the "Configuring nsswitch.conf"
section in the sudoers.ldap manual for details. Note that sudo will use
/etc/nsswitch.conf even if the underlying operating system does not support it.
To disable nsswitch support, run configure with the --with-nsswitch=no option.
To disable nsswitch support, run configure with the `--with-nsswitch=no` option.
This will cause sudo to consult LDAP first and /etc/sudoers second, unless the
ignore_sudoers_file flag is set in the global LDAP options.
Debugging your LDAP configuration
=================================
Enable debugging if you believe sudo is not parsing LDAP the way you think it
should. Setting the 'sudoers_debug' parameter to a value of 1 shows moderate
debugging. A value of 2 shows the results of the matches themselves. Make

103
README.md Normal file
View File

@@ -0,0 +1,103 @@
## The sudo philosophy
Sudo is a program designed to allow a sysadmin to give limited root privileges
to users and log root activity. The basic philosophy is to give as few
privileges as possible but still allow people to get their work done.
## Where to find sudo
Before you try and build sudo, *please* make sure you have the current
version. The latest sudo may always be gotten via anonymous ftp from
ftp.sudo.ws in the directory /pub/sudo/ or from the sudo web site,
https://www.sudo.ws/
The distribution is sudo-M.m.tar.gz where _M_ is the major version
number and _m_ is the minor version number. Beta versions of sudo may
also be available. If you join the _sudo-workers_ mailing list you
will get the beta announcements (see the Mailing lists section below).
## What's new
See the NEWS file for a list of major changes in this release. For
a complete list of changes, see the [ChangeLog](ChangeLog).
For a summary of major changes to the current stable release, see
https://www.sudo.ws/releases/stable/.
If you are upgrading from an earlier version of Sudo, please read
[docs/UPGRADE.md](docs/UPGRADE.md) for information on changes in
behavior that may affect you.
For a history of sudo please see [docs/HISTORY.md](docs/HISTORY.md).
You can find a list of contributors to sudo in
[docs/CONTRIBUTORS.md](docs/CONTRIBUTORS.md).
## Building the release
Please read the installation guide, [INSTALL.md](INSTALL.md), before
trying to build sudo. Pay special attention to the "OS dependent notes"
section.
## How to contribute
See [docs/CONTRIBUTING.md](docs/CONTRIBUTING.md) for information on
how you can help contribute to sudo.
## Copyright
Sudo is distributed under an ISC-style license.
Please refer to [docs/LICENSE.md](docs/LICENSE.md) for details.
## Mailing lists
#### sudo-announce
This list receives announcements whenever a new version of sudo is
released. https://www.sudo.ws/mailman/listinfo/sudo-announce
#### sudo-blog
This list receives a message when a new sudo blog article is
available. https://www.sudo.ws/mailman/listinfo/sudo-blog
#### sudo-commits
This list receives a message for each commit made to the sudo source
repository. https://www.sudo.ws/mailman/listinfo/sudo-commits
#### sudo-users
This list is for questions and general discussion about sudo.
https://www.sudo.ws/mailman/listinfo/sudo-users
#### sudo-workers
This list is for people working on and porting sudo.
https://www.sudo.ws/mailman/listinfo/sudo-workers
To subscribe to a list, visit its url (listed above) and enter your
email address to subscribe. Digest versions are available but these are
fairly low traffic lists so the digest versions are not a significant win.
Mailing list archives are also available. See the mailing list web sites
for the appropriate links.
## Web page
There is a sudo web page at https://www.sudo.ws/ that contains an overview
of sudo, documentation, downloads, a bug tracker, the sudo blog, information
about beta versions and other useful info.
## Bug reports
If you have found what you believe to be a bug, you can file a bug
report in the sudo bug database, at https://bugzilla.sudo.ws/.
Alternately, you can file a GitHub issue if that is easier for you
at https://github.com/sudo-project/sudo/issues/.
Please see [docs/SECURITY.md](docs/SECURITY.md) for our security
policy and how to report security issues.
Please read over [docs/TROUBLESHOOTING.md](docs/TROUBLESHOOTING.md)
*before* submitting a bug report. When reporting bugs, please be
sure to include the version of sudo you are using as well as the
platform you are running it on.

10
docs/CONTRIBUTING.md
View File

@@ -5,9 +5,9 @@ number of way you can help make Sudo better.
## Getting started
To get an overview of Sudo, please read the [README](../README). There
are multiple ways to contribute, some of which don't require writing
a single line of code.
To get an overview of Sudo, please read the [README.md](../README.md).
There are multiple ways to contribute, some of which don't require
writing a single line of code.
## Filing bug reports/issues
@@ -18,8 +18,8 @@ email, messages may be sent to the [sudo-workers@sudo.ws
mailing list](https://www.sudo.ws/mailman/listinfo/sudo-workers)
(public) or to sudo@sudo.ws (private).
For information on reporting security issues, please see the
[SECURITY](docs/SECURITY.md) file.
For information on reporting security issues, please see
[SECURITY.md](SECURITY.md).
Please include the version of sudo you are using, the operating
system and/or distro that is affected, and step-by-step instructions

2
docs/CONTRIBUTORS → docs/CONTRIBUTORS.md
View File

@@ -1,4 +1,4 @@
The following list of people, sorted by last name, have contributed
The following list of people, sorted by last name, have contributed
code or patches to this implementation of sudo since I began
maintaining it in 1993. This list is known to be incomplete--if
you believe you should be listed, please send a note to sudo@sudo.ws.

21
docs/HISTORY → docs/HISTORY.md
View File

@@ -1,6 +1,7 @@
A Brief History of Sudo:
A Brief History of Sudo
=======================
The Early Years
## The Early Years
Sudo was first conceived and implemented by Bob Coggeshall and Cliff Spencer
around 1980 at the Department of Computer Science at SUNY/Buffalo. It ran on
@@ -8,19 +9,19 @@ a VAX-11/750 running 4.1BSD. An updated version, credited to Phil Betchel,
Cliff Spencer, Gretchen Phillips, John LoVerso and Don Gworek, was posted to
the net.sources Usenet newsgroup in December of 1985.
Sudo at CU-Boulder
## Sudo at CU-Boulder
In the Summer of 1986, Garth Snyder released an enhanced version of sudo.
For the next 5 years, sudo was fed and watered by a handful of folks at
CU-Boulder, including Bob Coggeshall, Bob Manchek, and Trent Hein.
Root Group Sudo
## Root Group Sudo
In 1991, Dave Hieb and Jeff Nieusma wrote a new version of sudo with an
enhanced sudoers format under contract to a consulting firm called "The Root
Group". This version was later released under the GNU public license.
CU Sudo
## CU Sudo
In 1994, after maintaining sudo informally within CU-Boulder for some time,
Todd C. Miller made a public release of "CU sudo" (version 1.3) with bug
@@ -35,7 +36,7 @@ In 1996, Todd, who had been maintaining sudo for several years in his spare
time, moved distribution of sudo from a CU-Boulder ftp site to his domain,
courtesan.com.
Just Plain Sudo
## Just Plain Sudo
In 1999, the "CU" prefix was dropped from the name since there had been no
formal release of sudo from "The Root Group" since 1991 (the original
@@ -46,20 +47,20 @@ license.
In 2001, the sudo web site, ftp site and mailing lists were moved from
courtesan.com to the sudo.ws domain (sudo.org was already taken).
LDAP Integration
## LDAP Integration
In 2003, Nationwide Mutual Insurance Company contributed code written by
Aaron Spangler to store the sudoers data in LDAP. These changes were
incorporated into Sudo 1.6.8.
New Parser
## New Parser
In 2005, Todd rewrote the sudoers parser to better support the features that
had been added in the past ten years. This new parser removes some
limitations of the previous one, removes ordering constraints and adds
support for including multiple sudoers files.
Quest Sponsorship
## Quest Sponsorship
In 2010, Quest Software began sponsoring Sudo development by hiring
Todd to work on Sudo as part of his full-time job. This enabled
@@ -67,7 +68,7 @@ the addition of I/O logging, the plugin API, the log server,
additional regression and fuzz tests, support for binary packages
and more regular releases.
Present Day
## Present Day
Sudo, in its current form, is maintained by:

347
docs/LICENSE
View File

@@ -1,347 +0,0 @@
Sudo is distributed under the following license:
Copyright (c) 1994-1996, 1998-2021
Todd C. Miller <Todd.Miller@sudo.ws>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Sponsored in part by the Defense Advanced Research Projects
Agency (DARPA) and Air Force Research Laboratory, Air Force
Materiel Command, USAF, under agreement number F39502-99-1-0512.
The Python plugin bindings bear the following license:
Copyright (c) 2019-2020 Robert Manner <robert.manner@oneidentity.com>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The files hostcheck.c and hostcheck.h bear the following license:
Copyright (c) 2020 Laszlo Orban <laszlo.orban@oneidentity.com>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The file redblack.c bears the following license:
Copyright (c) 2001 Emin Martinian
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that neither the name of Emin
Martinian nor the names of any contributors are be used to endorse or
promote products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The file sssd.c bears the following license:
Copyright (c) 2011 Daniel Kopecek <dkopecek@redhat.com>
This code is derived from software contributed by Aaron Spangler.
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The files bsm_audit.c and bsm_audit.h bear the following license:
Copyright (c) 2009 Christian S.J. Peron
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The files solaris_audit.c and solaris_audit.h bear the following license:
Copyright (c) 2014, Oracle and/or its affiliates.
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The file reallocarray.c bears the following license:
Copyright (c) 2008 Otto Moerbeek <otto@drijf.net>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The files getcwd.c, glob.c, glob.h, snprintf.c and sudo_queue.h bear the
following license:
Copyright (c) 1989, 1990, 1991, 1993
The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
The file fnmatch.c bears the following license:
Copyright (c) 2011, VMware, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the VMware, Inc. nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL VMWARE, INC. OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The file getopt_long.c bears the following license:
Copyright (c) 2000 The NetBSD Foundation, Inc.
All rights reserved.
This code is derived from software contributed to The NetBSD Foundation
by Dieter Baron and Thomas Klausner.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
The file inet_pton.c bears the following license:
Copyright (c) 1996 by Internet Software Consortium.
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS
ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE
CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
The file arc4random.c bears the following license:
Copyright (c) 1996, David Mazieres <dm@uun.org>
Copyright (c) 2008, Damien Miller <djm@openbsd.org>
Copyright (c) 2013, Markus Friedl <markus@openbsd.org>
Copyright (c) 2014, Theo de Raadt <deraadt@openbsd.org>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The file arc4random_uniform.c bears the following license:
Copyright (c) 2008, Damien Miller <djm@openbsd.org>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The file getentropy.c bears the following license:
Copyright (c) 2014 Theo de Raadt <deraadt@openbsd.org>
Copyright (c) 2014 Bob Beck <beck@obtuse.com>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The embedded copy of zlib bears the following license:
Copyright (C) 1995-2017 Jean-loup Gailly and Mark Adler
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly Mark Adler
jloup@gzip.org madler@alumni.caltech.edu
The embedded copy of protobuf-c bears the following license:
Copyright (c) 2008-2018, Dave Benson and the protobuf-c authors.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

347
docs/LICENSE.md Normal file
View File

@@ -0,0 +1,347 @@
Sudo is distributed under the following license:
Copyright (c) 1994-1996, 1998-2021
Todd C. Miller <Todd.Miller@sudo.ws>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Sponsored in part by the Defense Advanced Research Projects
Agency (DARPA) and Air Force Research Laboratory, Air Force
Materiel Command, USAF, under agreement number F39502-99-1-0512.
The Python plugin bindings bear the following license:
Copyright (c) 2019-2020 Robert Manner <robert.manner@oneidentity.com>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The files hostcheck.c and hostcheck.h bear the following license:
Copyright (c) 2020 Laszlo Orban <laszlo.orban@oneidentity.com>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The file redblack.c bears the following license:
Copyright (c) 2001 Emin Martinian
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that neither the name of Emin
Martinian nor the names of any contributors are be used to endorse or
promote products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The file sssd.c bears the following license:
Copyright (c) 2011 Daniel Kopecek <dkopecek@redhat.com>
This code is derived from software contributed by Aaron Spangler.
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The files bsm_audit.c and bsm_audit.h bear the following license:
Copyright (c) 2009 Christian S.J. Peron
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The files solaris_audit.c and solaris_audit.h bear the following license:
Copyright (c) 2014, Oracle and/or its affiliates.
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The file reallocarray.c bears the following license:
Copyright (c) 2008 Otto Moerbeek <otto@drijf.net>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The files getcwd.c, glob.c, glob.h, snprintf.c and sudo_queue.h bear the
following license:
Copyright (c) 1989, 1990, 1991, 1993
The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
The file fnmatch.c bears the following license:
Copyright (c) 2011, VMware, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the VMware, Inc. nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL VMWARE, INC. OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The file getopt_long.c bears the following license:
Copyright (c) 2000 The NetBSD Foundation, Inc.
All rights reserved.
This code is derived from software contributed to The NetBSD Foundation
by Dieter Baron and Thomas Klausner.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
The file inet_pton.c bears the following license:
Copyright (c) 1996 by Internet Software Consortium.
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS
ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE
CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
The file arc4random.c bears the following license:
Copyright (c) 1996, David Mazieres <dm@uun.org>
Copyright (c) 2008, Damien Miller <djm@openbsd.org>
Copyright (c) 2013, Markus Friedl <markus@openbsd.org>
Copyright (c) 2014, Theo de Raadt <deraadt@openbsd.org>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The file arc4random_uniform.c bears the following license:
Copyright (c) 2008, Damien Miller <djm@openbsd.org>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The file getentropy.c bears the following license:
Copyright (c) 2014 Theo de Raadt <deraadt@openbsd.org>
Copyright (c) 2014 Bob Beck <beck@obtuse.com>
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The embedded copy of zlib bears the following license:
Copyright (C) 1995-2017 Jean-loup Gailly and Mark Adler
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly Mark Adler
jloup@gzip.org madler@alumni.caltech.edu
The embedded copy of protobuf-c bears the following license:
Copyright (c) 2008-2018, Dave Benson and the protobuf-c authors.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

10
docs/Makefile.in
View File

@@ -88,11 +88,13 @@ DEVDOCS = $(srcdir)/cvtsudoers.man.in $(srcdir)/sudo.conf.man.in \
$(srcdir)/sudoers.man.in $(srcdir)/sudoers_timestamp.man.in \
$(srcdir)/sudoreplay.man.in $(srcdir)/visudo.man.in
OTHER_DOCS = $(top_srcdir)/ChangeLog $(top_srcdir)/README \
$(top_srcdir)/NEWS $(srcdir)/HISTORY $(srcdir)/CONTRIBUTORS \
$(srcdir)/LICENSE $(srcdir)/TROUBLESHOOTING $(srcdir)/UPGRADE
OTHER_DOCS = $(top_srcdir)/ChangeLog $(top_srcdir)/NEWS \
$(top_srcdir)/README.md $(srcdir)/CONTRIBUTING.md \
$(srcdir)/CONTRIBUTORS.md $(srcdir)/HISTORY.md \
$(srcdir)/LICENSE.md $(srcdir)/SECURITY.md \
$(srcdir)/TROUBLESHOOTING.md $(srcdir)/UPGRADE.md
OTHER_DOCS_LDAP = $(top_srcdir)/README.LDAP $(srcdir)/schema.*
OTHER_DOCS_LDAP = $(top_srcdir)/README.LDAP.md $(srcdir)/schema.*
VERSION = @PACKAGE_VERSION@
PACKAGE_TARNAME = @PACKAGE_TARNAME@

295
docs/TROUBLESHOOTING
View File

@@ -1,295 +0,0 @@
Troubleshooting tips and FAQ for Sudo
=====================================
Q) When I run configure, it says "C compiler cannot create executables".
A) This usually means you either don't have a working compiler. This
could be due to the lack of a license or that some component of the
compiler suite could not be found. Check config.log for clues as
to why this is happening. On many systems, compiler components live
in /usr/ccs/bin which may not be in your PATH environment variable.
Q) When I run configure, it says "sudo requires the 'ar' utility to build".
A) As part of the build process, sudo creates a temporary library containing
objects that are shared amongst the different sudo executables.
On Unix systems, the "ar" utility is used to do this. This error
indicates that "ar" is missing on your system. On Solaris systems,
you may need to install the SUNWbtool package. On other systems
"ar" may be included in the GNU binutils package.
Q) Sudo compiles and installs OK but when I try to run it I get:
/usr/local/bin/sudo must be owned by uid 0 and have the setuid bit set
A) Sudo must be setuid root to do its work. Either /usr/local/bin/sudo
is not owned by uid 0 or the setuid bit is not set. This should have
been done for you by "make install" but you can fix it manually by
running the following as root:
# chown root /usr/local/bin/sudo; chmod 4755 /usr/local/bin/sudo
Q) Sudo compiles and installs OK but when I try to run it I get:
effective uid is not 0, is /usr/local/bin/sudo on a file system with the
'nosuid' option set or an NFS file system without root privileges?
A) The owner and permissions on the sudo binary appear to be OK but when
sudo ran, the setuid bit did not have an effect. There are two common
causes for this. The first is that the file system the sudo binary
is located on is mounted with the 'nosuid' mount option, which disables
setuid binaries. The output of the "mount" command should tell you if
the file system is mounted with the 'nosuid' option. The other possible
cause is that sudo is installed on an NFS-mounted file system that is
exported without root privileges. By default, NFS file systems are
exported with uid 0 mapped to a non-privileged uid (usually -2). You
should be able to determine whether sudo is located on an NFS-mounted
filesystem by running "df `which sudo'".
Q) Sudo never gives me a chance to enter a password using PAM, it just
says 'Sorry, try again.' three times and exits.
A) You didn't setup PAM to work with sudo. On RedHat Linux or Fedora
Core this generally means installing the sample pam.conf file as
/etc/pam.d/sudo. See the example pam.conf file for hints on what
to use for other Linux systems.
Q) Sudo says 'Account expired or PAM config lacks an "account"
section for sudo, contact your system administrator' and exits
but I know my account has not expired.
A) Your PAM config lacks an "account" specification. On Linux this
usually means you are missing a line like:
account required pam_unix.so
in /etc/pam.d/sudo.
Q) Sudo is setup to log via syslog(3) but I'm not getting any log
messages.
A) Make sure you have an entry in your syslog.conf file to save
the sudo messages (see the example syslog.conf file). The default
log facility is authpriv (changeable via configure or in sudoers).
Don't forget to send a SIGHUP to your syslogd so that it re-reads
its conf file. Also, remember that syslogd does *not* create
log files, you need to create the file before syslogd will log
to it (ie: touch /var/log/sudo).
Note: the facility (e.g. "auth.debug") must be separated from the
destination (e.g. "/var/log/auth" or "@loghost") by
tabs, *not* spaces. This is a common error.
Q) When sudo asks me for my password it never accepts what I enter even
though I know I entered my password correctly.
A) If you are not using pam and your system uses shadow passwords,
it is possible that sudo didn't properly detect that shadow
passwords are in use. Take a look at the generated config.h
file and verify that the C function used for shadow password
look ups was detected. For instance, for SVR4-style shadow
passwords, HAVE_GETSPNAM should be defined (you can search for
the string "shadow passwords" in config.h with your editor).
Note that there is no define for 4.4BSD-based shadow passwords
since that just uses the standard getpw* routines.
Q) Can sudo use the ssh agent for authentication instead of asking
for the user's Unix password?
A) Not directly, but you can use a PAM module like pam_ssh_agent_auth
or pam_ssh for this purpose.
Q) I don't want the sudoers file in /etc, how can I specify where it
should go?
A) Use the --sysconfdir option to configure. Ie:
configure --sysconfdir=/dir/you/want/sudoers/in
Q) Can I put the sudoers file in NIS/NIS+ or do I have to have a
copy on each machine?
A) There is no support for making an NIS/NIS+ map/table out of
the sudoers file at this time. You can distribute the sudoers
file via rsync or rdist. It is also possible to NFS-mount the
sudoers file. If you use LDAP at your site you may be interested
in sudo's LDAP sudoers support, see the README.LDAP file and the
sudoers.ldap manual.
Q) I don't run sendmail on my machine. Does this mean that I cannot
use sudo?
A) No, you just need to disable mailing with a line like:
Defaults !mailerpath
in your sudoers file or run configure with the --without-sendmail
option.
Q) When I run visudo it uses vi as the editor and I hate vi. How
can I make it use another editor?
A) You can specify the editor to use in visudo in the sudoers file.
See the "editor" and "env_editor" entries in the sudoers manual.
The defaults can also be set at configure time using the
--with-editor and --with-env-editor configure options.
Q) Sudo appears to be removing some variables from the environment, why?
A) By default, sudo runs commands with a new, minimal environment.
The "env_keep" setting in sudoers can be used to control which
environment variables are preserved from the invoking user's
environment via the "env_keep" setting in sudoers.
While it is possible to disable the "env_reset" setting, which
will preserve all environment variables that don't match a black
list, doing so is strongly discouraged. See the "Command
environment" section of the sudoers manual for more information.
Q) Why does sudo reset the HOME environment variable?
A) Many programs use the HOME environment variable to locate
configuration and data files. Often, these configuration files
are treated as trusted input that affects how the program operates.
By controlling the configuration files, a user may be able to
cause the program to execute other commands without sudo's
restrictions or logging.
Some programs perform extra checks when the real and effective
user-IDs differ, but because sudo runs commands with all user-IDs
set to the target user, these checks are insufficient.
While it is possible to preserve the value of the HOME environment
variable by adding it to the "env_keep" list in the sudoers file,
doing so is strongly discouraged. Users wishing to edit files
with sudo should run sudoedit (or sudo -e) to get their accustomed
editor configuration instead of invoking the editor directly.
Q) How can I keep sudo from asking for a password?
A) To specify this on a per-user (and per-command) basis, use the
'NOPASSWD' tag right before the command list in sudoers. See
the sudoers man page and examples/sudoers for details. To disable
passwords completely, add !authenticate" to the Defaults line
in /etc/sudoers. You can also turn off authentication on a
per-user or per-host basis using a user or host-specific Defaults
entry in sudoers. To hard-code the global default, you can
configure with the --without-passwd option.
Q) When I run configure, it dies with the following error:
"no acceptable cc found in $PATH".
A) /usr/ucb/cc was the only C compiler that configure could find.
You need to tell configure the path to the "real" C compiler
via the --with-CC option. On Solaris, the path is probably
something like "/opt/SUNWspro/SC4.0/bin/cc". If you have gcc
that will also work.
Q) When I run configure, it dies with the following error:
Fatal Error: config.cache exists from another platform!
Please remove it and re-run configure.
A) configure caches the results of its tests in a file called
config.cache to make re-running configure speedy. However,
if you are building sudo for a different platform the results
in config.cache will be wrong so you need to remove config.cache.
You can do this by "rm config.cache" or "make realclean".
Note that "make realclean" will also remove any object files
and configure temp files that are laying around as well.
Q) I built sudo on a Solaris 11 (or higher) machine but the resulting
binary doesn't work older Solaris versions. Why?
A) Starting with Solaris 11, asprintf(3) is included in the standard
C library. To build a version of sudo on a Solaris 11 machine that
will run on an older Solaris release, edit config.h and comment out
the lines:
#define HAVE_ASPRINTF 1
#define HAVE_VASPRINTF 1
and run make.
Q) When I run "visudo" it says "sudoers file busy, try again later."
and doesn't do anything.
A) Someone else is currently editing the sudoers file with visudo.
Q) When I try to use "cd" with sudo it says "cd: command not found".
A) "cd" is a shell built-in command, you can't run it as a command
since a child process (sudo) cannot affect the current working
directory of the parent (your shell).
Q) When I try to use "cd" with sudo the command completes without
errors but nothing happens.
A) Even though "cd" is a shell built-in command, some operating systems
include a /usr/bin/cd command for some reason. A standalone
"cd" command is totally useless since a child process (cd) cannot
affect the current working directory of the parent (your shell).
Thus, "sudo cd /foo" will start a child process, change the
directory and immediately exit without doing anything useful.
Q) When I run sudo it says I am not allowed to run the command as root
but I don't want to run it as root, I want to run it as another user.
My sudoers file entry looks like:
bob ALL=(oracle) ALL
A) The default user sudo tries to run things as is always root, even if
the invoking user can only run commands as a single, specific user.
This may change in the future but at the present time you have to
work around this using the 'runas_default' option in sudoers.
For example:
Defaults:bob runas_default=oracle
would achieve the desired result for the preceding sudoers fragment.
Q) When I try to run sudo via ssh, I get the error:
sudo: a terminal is required to read the password; either use the -S
option to read from standard input or configure an askpass helper
A) If sudo needs to authenticate a user, it requires access to the user's
terminal to disable echo so the password is not displayed to the screen.
The above message indicates that no terminal was present.
When running a command via ssh, a terminal is not allocated by default
which can cause this message. The "-t" option to ssh will force it to
allocate a tty. Alternately, you may be able to use the ssh-askpass
utility to prompt for the password if X11 forwarding is enabled and an
askpass helper is configured in the sudo.conf file. If you do not mind
your password being echoed to the screen, you may use sudo's -S option
to read the password from the standard input. Alternately, you may set
the "visiblepw" sudoers option which will allow the password to be entered
even when echo cannot be disabled, though this is not recommended.
Q) When I try to use SSL-enabled LDAP with sudo I get an error:
unable to initialize SSL cert and key db: security library: bad database.
you must set TLS_CERT in /etc/ldap.conf to use SSL
A) On systems that use a Mozilla-derived LDAP SDK there must be a
certificate database in place to use SSL-encrypted LDAP connections.
This file is usually /var/ldap/cert8.db or /etc/ldap/cert8.db.
The actual number after "cert" will vary, depending on the version
of the LDAP SDK that is being used. If you do not have a certificate
database you can either copy one from a mozilla-derived browser, such
as firefox, or create one using the "certutil" command. You can run
"certutil" as follows and press the <return> (or <enter>) key at the
password prompt:
# certutil -N -d /var/ldap
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.
Enter new password: <return>
Re-enter password: <return>
Q) On HP-UX, the umask setting in sudoers has no effect.
A) If your /etc/pam.conf file has the libpam_hpsec.so.1 session module
enabled, you may need to a add line like the following to pam.conf:
sudo session required libpam_hpsec.so.1 bypass_umask
Q) When I run "sudo -i shell_alias" I get "command not found" even
though the alias is defined in my shell startup files.
A) Commands run via "sudo -i" are executed by the shell in
non-interactive mode. The bash shell will only parse aliases in
interactive mode unless the "expand_aliases" shell option is
set. If you add "shopt -s expand_aliases" to your .bash_profile
(or .profile if using that instead) the aliases should now be
available to "sudo -i".
Q) When I run sudo on AIX I get the following error:
setuidx(ID_EFFECTIVE|ID_REAL|ID_SAVED, ROOT_UID): Operation not permitted.
A) AIX's Enhanced RBAC is preventing sudo from running. To fix
this, add the following entry to /etc/security/privcmds (adjust
the path to sudo as needed) and run the setkst command as root:
/usr/local/bin/sudo:
accessauths = ALLOW_ALL
innateprivs = PV_DAC_GID,PV_DAC_R,PV_DAC_UID,PV_DAC_X,PV_FS_CHOWN,PV_PROC_PRIO,PV_NET_PORT,PV_NET_CNTL,PV_SU_UID
secflags = FSF_EPS
Q) Sudo configures and builds without error but when I run it I get
a Segmentation fault.
A) If you are on a Linux system, the first thing to try is to run
configure with the --disable-pie option, then "make clean" and
"make". If that fixes the problem then your operating system
does not properly support position independent executables.
Please send a message to sudo@sudo.ws with system details such
as the Linux distro, kernel version and CPU architecture.
Q) When I run configure I get the following error:
dlopen present but libtool doesn't appear to support your platform.
A) Libtool doesn't know how to support dynamic linking on the operating
system you are building for. If you are cross-compiling, you need to
specify the operating system, not just the CPU type. For example:
--host powerpc-unknown-linux
instead of just:
--host powerpc
Q) How do you pronounce `sudo'?
A) The official pronunciation is soo-doo (for su "do"). However, an
alternate pronunciation, a homophone of "pseudo", is also common.

337
docs/TROUBLESHOOTING.md Normal file
View File

@@ -0,0 +1,337 @@
Troubleshooting tips and FAQ for Sudo
=====================================
#### When I run configure, it says "C compiler cannot create executables".
> This usually means you either don't have a working compiler. This
> could be due to the lack of a license or that some component of the
> compiler suite could not be found. Check config.log for clues as
> to why this is happening. On many systems, compiler components live
> in /usr/ccs/bin which may not be in your PATH environment variable.
#### When I run configure, it says "sudo requires the 'ar' utility to build".
> As part of the build process, sudo creates a temporary library
> containing objects that are shared amongst the different sudo
> executables. On Unix systems, the 'ar' utility is used to do this.
> This error indicates that 'ar' is missing on your system. On Solaris
> systems, you may need to install the SUNWbtool package. On other
> systems 'ar' may be included in the GNU binutils package.
#### Sudo compiles and installs successfully but when I try to run it I get:
/usr/local/bin/sudo must be owned by uid 0 and have the setuid bit set
> Sudo must be setuid root to do its work. Either /usr/local/bin/sudo
> is not owned by uid 0 or the setuid bit is not set. This should have
> been done for you by `make install` but you can fix it manually by
> running the following as root:
chown root /usr/local/bin/sudo; chmod 4755 /usr/local/bin/sudo
#### Sudo compiles and installs OK but when I try to run it I get:
effective uid is not 0, is /usr/local/bin/sudo on a file system with the
'nosuid' option set or an NFS file system without root privileges?
> The owner and permissions on the sudo binary appear to be OK but when
> sudo ran, the setuid bit did not have an effect. There are two common
> causes for this. The first is that the file system the sudo binary
> is located on is mounted with the 'nosuid' mount option, which disables
> setuid binaries. The output of the 'mount' command should tell you if
> the file system is mounted with the 'nosuid' option. The other possible
> cause is that sudo is installed on an NFS-mounted file system that is
> exported without root privileges. By default, NFS file systems are
> exported with uid 0 mapped to a non-privileged uid (usually -2). You
> should be able to determine whether sudo is located on an NFS-mounted
> filesystem by running "df \`which sudo\`".
#### Sudo never gives me a chance to enter a password using PAM
It just says "Sorry, try again." three times and exits.
> You didn't setup PAM to work with sudo. On RedHat or Fedora Linux
> this generally means installing the sample pam.conf file as
> /etc/pam.d/sudo. See the example pam.conf file for hints on what
> to use for other Linux systems.
#### Sudo says my account has expired but I know it has not
> If you get the following error from sudo:
Account expired or PAM config lacks an 'account' section for sudo,
contact your system administrator`
> when the account has not expired, your PAM config probably lacks
> an 'account' specification. On Linux this usually means you are
> missing a line in /etc/pam.d/sudo similar to:
account required pam_unix.so
#### Sudo is configured use syslog but nothing gets logged
> Make sure you have an entry in your syslog.conf file to save
> the sudo messages (see the example syslog.conf file). The default
> log facility is authpriv (changeable via configure or in sudoers).
> Don't forget to send a SIGHUP to your syslogd so that it re-reads
> its conf file. Also, remember that syslogd does *not* create
> log files, you need to create the file before syslogd will log
> to it (ie: touch /var/log/sudo).
> Note: the facility (e.g. 'auth.debug') must be separated from
> the destination (e.g. '/var/log/auth' or '@loghost') by tabs,
> *not* spaces. This is a common error.
#### Sudo won't accept my password, even when entered correctly
> If you are not using pam and your system uses shadow passwords,
> it is possible that sudo didn't properly detect that shadow
> passwords are in use. Take a look at the generated config.h
> file and verify that the C function used for shadow password
> look ups was detected. For instance, for SVR4-style shadow
> passwords, `HAVE_GETSPNAM` should be defined (you can search for
> the string 'shadow passwords' in config.h with your editor).
> Note that there is no define for 4.4BSD-based shadow passwords
> since that just uses the standard getpw* routines.
#### Can sudo use the ssh agent instead of asking for the user's password?
> Not directly, but you can use a PAM module like pam_ssh_agent_auth
> or pam_ssh for this purpose.
#### I want to place the sudoers file in a directory other than /etc
> Use the `--sysconfdir` option to configure. For example:
configure --sysconfdir=/dir/you/want/sudoers/in
> Alternately, you can set the path in the sudo.conf file as an
> argument to the sudoers.so plugin. For example:
Plugin sudoers_policy sudoers.so sudoers_file=/path/to/sudoers
#### Can I put the sudoers file in NIS/NIS+?
> There is no support for making an NIS/NIS+ map/table out of the sudoers
> file at this time. You can distribute the sudoers file via rsync or rdist.
> It is also possible to NFS-mount the sudoers file. If you use LDAP at your
> site you may be interested in sudo's LDAP sudoers support, see
> [README.LDAP.md](../README.LDAP.md) and the sudoers.ldap manual.
#### I don't run sendmail, does this mean that I cannot use sudo?
> No, you just need to disable mailing with a line like:
Defaults !mailerpath
> in your sudoers file or run configure with the `--without-sendmail`
> option.
#### How can I make visudo use a different editor?
> You can specify the editor to use in visudo in the sudoers file.
> See the 'editor' and 'env_editor' entries in the sudoers manual.
> The defaults can also be set at configure time using the
> `--with-editor` and `--with-env-editor` configure options.
#### Why does sudo modify the command's environment?
> By default, sudo runs commands with a new, minimal environment.
> The 'env_keep' setting in sudoers can be used to control which
> environment variables are preserved from the invoking user's
> environment via the 'env_keep' setting in sudoers.
>
> While it is possible to disable the 'env_reset' setting, which
> will preserve all environment variables that don't match a black
> list, doing so is strongly discouraged. See the "Command
> environment" section of the sudoers manual for more information.
#### Why does sudo reset the HOME environment variable?
> Many programs use the HOME environment variable to locate
> configuration and data files. Often, these configuration files
> are treated as trusted input that affects how the program operates.
> By controlling the configuration files, a user may be able to
> cause the program to execute other commands without sudo's
> restrictions or logging.
>
> Some programs perform extra checks when the real and effective
> user-IDs differ, but because sudo runs commands with all user-IDs
> set to the target user, these checks are insufficient.
>
> While it is possible to preserve the value of the HOME environment
> variable by adding it to the 'env_keep' list in the sudoers file,
> doing so is strongly discouraged. Users wishing to edit files
> with sudo should run sudoedit (or sudo -e) to get their accustomed
> editor configuration instead of invoking the editor directly.
#### How can I prevent sudo from asking for a password?
> To specify this on a per-user (and per-command) basis, use the
> 'NOPASSWD' tag right before the command list in sudoers. See
> the sudoers man page and examples/sudoers for details. To disable
> passwords completely, add '!authenticate' to the Defaults line
> in /etc/sudoers. You can also turn off authentication on a
> per-user or per-host basis using a user or host-specific Defaults
> entry in sudoers. To hard-code the global default, you can
> configure with the `--without-passwd` option.
#### The configure scripts says `no acceptable cc found in $PATH`
> /usr/ucb/cc was the only C compiler that configure could find.
> You need to tell configure the path to the 'real' C compiler
> via the `--with-CC option`. On Solaris, the path is probably
> something like /opt/SUNWspro/SC4.0/bin/cc. If you have gcc
> that will also work.
#### The configure scripts says "config.cache exists from another platform!"
> configure caches the results of its tests in a file called
> config.cache to make re-running configure speedy. However,
> if you are building sudo for a different platform the results
> in config.cache will be wrong so you need to remove the config.cache file.
> You can do this via `rm config.cache` or `make realclean`.
> Note that `make realclean` will also remove any object files
> and configure temp files that are laying around as well.
#### Why don't sudo binaries built on Solaris 11 run on Solaris 10?
> Starting with Solaris 11, asprintf(3) is included in the standard
> C library. To build a version of sudo on a Solaris 11 machine that
> will run on an older Solaris release, edit config.h and comment out
> the lines:
#define HAVE_ASPRINTF 1
#define HAVE_VASPRINTF 1
> and run make.
#### When I run 'visudo' it says "sudoers file busy, try again later."
> Someone else is currently editing the sudoers file with visudo.
#### When I try to use 'cd' with sudo it says "cd: command not found"
> 'cd' is a shell built-in command, you can't run it as a command
> since a child process (sudo) cannot affect the current working
> directory of the parent (your shell).
#### When I try to use 'cd' with sudo nothing happens.
> Even though 'cd' is a shell built-in command, some operating systems
> include a /usr/bin/cd command for completeness. A standalone
> "cd' command is totally useless since a child process (cd) cannot
> affect the current working directory of the parent (your shell).
> Thus, `sudo cd /foo` will start a child process, change the
> directory and immediately exit without doing anything useful.
#### How can I run a command via sudo as a user other than root?
> The default user sudo tries to run things as is always root, even if
> the invoking user can only run commands as a single, specific user.
> This may change in the future but at the present time you have to
> work around this using the 'runas_default' option in sudoers.
> For example, given the following sudoers rule:
bob ALL=(oracle) ALL
> You can cause sudo to run all commands as 'oracle' for user 'bob'
> with a sudoers entry like:
Defaults:bob runas_default=oracle
#### When I try to run sudo via ssh, I get an error:
sudo: a terminal is required to read the password; either use the -S
option to read from standard input or configure an askpass helper
> If sudo needs to authenticate a user, it requires access to the user's
> terminal to disable echo so the password is not displayed to the screen.
> The above message indicates that no terminal was present.
> When running a command via ssh, a terminal is not allocated by default
> which can cause this message. The '-t' option to ssh will force it to
> allocate a tty. Alternately, you may be able to use the ssh-askpass
> utility to prompt for the password if X11 forwarding is enabled and an
> askpass helper is configured in the sudo.conf file. If you do not mind
> your password being echoed to the screen, you may use sudo's -S option
> to read the password from the standard input. Alternately, you may set
> the 'visiblepw' sudoers option which will allow the password to be entered
> even when echo cannot be disabled, though this is not recommended.
#### When I try to use SSL-enabled LDAP with sudo I get an error:
unable to initialize SSL cert and key db: security library: bad database.
you must set TLS_CERT in /etc/ldap.conf to use SSL
> On systems that use a Mozilla-derived LDAP SDK there must be a
> certificate database in place to use SSL-encrypted LDAP connections.
> This file is usually /var/ldap/cert8.db or /etc/ldap/cert8.db.
> The actual number after 'cert' will vary, depending on the version
> of the LDAP SDK that is being used. If you do not have a certificate
> database you can either copy one from a mozilla-derived browser, such
> as firefox, or create one using the `certutil` command. You can run
> `certutil` as follows and press the <return> (or <enter>) key at the
> password prompt:
# certutil -N -d /var/ldap
> Enter a password which will be used to encrypt your keys.
> The password should be at least 8 characters long,
> and should contain at least one non-alphabetic character.
Enter new password: <return>
Re-enter password: <return>
#### On HP-UX, the umask setting in sudoers has no effect.
> If your /etc/pam.conf file has the libpam_hpsec.so.1 session module
> enabled, you may need to a add line like the following to pam.conf:
> sudo session required libpam_hpsec.so.1 bypass_umask
#### When I run `sudo -i shell_alias` I get "command not found"
> Commands run via `sudo -i` are executed by the shell in
> non-interactive mode. The bash shell will only parse aliases in
> interactive mode unless the 'expand_aliases' shell option is
> set. If you add `shopt -s expand_aliases` to your .bash_profile
> (or .profile if using that instead) the aliases should now be
> available to `sudo -i`.
#### When I run sudo on AIX I get the following error:
setuidx(ID_EFFECTIVE|ID_REAL|ID_SAVED, ROOT_UID): Operation not permitted.
> AIX's Enhanced RBAC is preventing sudo from running. To fix
> this, add the following entry to /etc/security/privcmds (adjust
> the path to sudo as needed) and run the setkst command as root:
/usr/local/bin/sudo:
accessauths = ALLOW_ALL
innateprivs = PV_DAC_GID,PV_DAC_R,PV_DAC_UID,PV_DAC_X,PV_FS_CHOWN,PV_PROC_PRIO,PV_NET_PORT,PV_NET_CNTL,PV_SU_UID
secflags = FSF_EPS
#### Sudo builds without error but when I run it I get a Segmentation fault.
> If you are on a Linux system, the first thing to try is to run
> configure with the `--disable-pie` option, then `make clean` and
> `make`. If that fixes the problem then your operating system
> does not properly support position independent executables.
> Please send a message to sudo@sudo.ws with system details such
> as the Linux distro, kernel version and CPU architecture.
#### When I run configure I get the following error:
dlopen present but libtool doesn't appear to support your platform.
> Libtool doesn't know how to support dynamic linking on the operating
> system you are building for. If you are cross-compiling, you need to
> specify the operating system, not just the CPU type. For example,
> `--host powerpc-unknown-linux`
> instead of just:
> `--host powerpc`
#### How do you pronounce 'sudo'?
> The official pronunciation is soo-doo (for su 'do'). However, an
> alternate pronunciation, a homophone of 'pseudo', is also common.

560
docs/UPGRADE
View File

@@ -1,560 +0,0 @@
Notes on upgrading from an older release
========================================
o Upgrading from a version prior to 1.9.9:
On systems where SELinux is enabled and sudo is built with
SELinux support, if the user's role is not "unconfined_r" sudo
will always execute commands via the "sesh" helper program.
Previously, commands were only executed via "sesh" if a role
was specified in the sudoers file rule or by the user on the
command line.
Sudo now runs commands with the core limit resource limit set
to 0 by default. While most operating systems restrict core
dumps of set-user-ID programs like sudo, this protection is
lost when sudo executes a command. By disabling core dumps by
default, it is possible to avoid potential security problems
such as those seen with the Linux logrotate utility, which could
interpret a core dump as a valid configuration file.
o Upgrading from a version prior to 1.9.7:
Sudo now links with OpenSSL 1.0.1 or higher by default if it
is present on the system unless it is explicitly disabled (via
--disable-openssl), or unless the sudo log client and server
code is disabled (via --disable-log-client and --disable-log-server).
As a result, the sudo log server (and the client built into the
sudoers plugin) now support TLS connections by default.
o Upgrading from a version prior to 1.9.3:
Due to the addition of the CHROOT and CWD options, it is no
longer possible to declare an alias with one of those names.
If a sudoers file has an alias with one of those names, sudo
and visudo will report a syntax error with a message like
"syntax error: unexpected CHROOT, expecting ALIAS".
Starting with version 1.9.3, sudoers rules must end in either
a newline or the end-of-file. This makes it possible to provide
better error messages. Previously, it was possible to include
multiple rules on a single line, separated by white space.
Starting with version 1.9.3, sudo will attempt to recover from
a syntax error in the sudoers file by discarding the portion
of the line that contains the error until the end of the line.
To restore the historic behavior of refusing to run when a
syntax error is encountered, add "error_recovery=false" as a
plugin option in sudo.conf for the "sudoers_audit" plugin, (or
"sudoers_policy" if there is no "sudoers_audit" plugin configured).
o Upgrading from a version prior to 1.9.1:
Starting with version 1.9.1, sudoers plugin arguments in sudo.conf
should be specified for the "sudoers_audit" plugin, not
"sudoers_policy". This is because the sudoers file is now
opened and parsed by the "sudoers_audit" plugin. Previously,
this was done by the "sudoers_policy" plugin. The use of an
audit plugin makes it possible for the sudoers module to detect
when a command has been rejected by an approval plugin and only
log commands that are allowed by both policy and approval
plugins.
o Upgrading from a version prior to 1.8.30:
Starting with version 1.8.30, sudo will no longer allow commands
to be run as a user or group ID that is not in the password or
group databases by default. Previously, sudo would always allow
unknown user or group IDs if the sudoers entry permitted it,
including via the "ALL" alias. The old behavior can be restored
by setting the new "allow_unknown_runas_id" Defaults setting
in the sudoers file.
o Upgrading from a version prior to 1.8.29:
Starting with version 1.8.29, if the umask is explicitly set
in sudoers, that value is used regardless of the umask specified
by PAM or login.conf. However, if the umask is not explicitly
set in sudoers, PAM or login.conf may now override the default
sudoers umask. Previously, the sudoers umask always overrode
the umask set by PAM, which was not the documented behavior.
o Upgrading from a version prior to 1.8.28:
Starting with version 1.8.28, sudo stores the signal that caused
a command to be suspended or resumed as a string in the I/O log
timing file. The version of sudoreplay included with sudo
1.8.28 can process either type of I/O log file but older versions
of sudoreplay are unable to replay the newer logs.
Starting with version 1.8.28, sudoedit honors the umask and
umask_override settings in sudoers. Previously, the user's
umask was used as-is.
o Upgrading from a version prior to 1.8.26:
Starting with version 1.8.26, sudo no long sets the USERNAME
environment variable when running commands. This is a non-standard
environment variable that was set on some older Linux systems.
Sudo still sets the LOGNAME, USER and, on AIX systems, LOGIN
environment variables.
Handling of the LOGNAME, USER (and on AIX, LOGIN) environment
variables has changed slightly in version 1.8.26. Sudo now
treats those variables as a single unit. This means that if
one variable is preserved or removed from the environment using
env_keep, env_check or env_delete, the others are too.
o Upgrading from a version prior to 1.8.23:
In sudo 1.8.23 the "sudoers2ldif" script and the "visudo -x"
functionality has been superseded by the "cvtsudoers" utility.
The cvtsudoers utility is intended to be a drop-in replacement
for "sudoers2ldif". Because it uses the same parser as sudo
and visudo, cvtsudoers can perform a more accurate conversion
than sudoers2ldif could.
To convert a sudoers file to JSON, the format option must be
specified. For example, instead of:
visudo -f sudoers_file -x output_file
one would use:
cvtsudoers -f json -o output_file sudoers_file
Note that unlike "visudo -x", "cvtsudoers" reads from the
standard input by default. Also, the base DN may be specified
on the command line, if desired, using the -b option.
o Upgrading from a version prior to 1.8.20:
Due to the addition of the TIMEOUT, NOTBEFORE and NOTAFTTER
options, it is no longer possible to declare an alias with one
of those names. If a sudoers file has an alias with one of
those names, sudo and visudo will report a syntax error with a
message like "syntax error: unexpected TIMEOUT, expecting ALIAS".
Starting with version 1.9.3, sudoers rules must end in either
Prior to version 1.8.20, when log_input, log_output or use_pty
were enabled, if any of the standard input, output or error
were not connected to a terminal, sudo would use a pipe. The
pipe allows sudo to interpose itself between the old standard
input, output or error and log the contents. Beginning with
version 1.8.20, a pipe is only used when I/O logging is enabled.
If use_pty is set without log_input or log_output, no pipe will
be used. Additionally, if log_input is set without log_output,
a pipe is only used for the standard input. Likewise, if
log_output is set without log_input, a pipe is only used for
the standard output and standard error. This results in a
noticeable change in behavior if the use_pty flag is set and no
terminal is present when running commands such as scripts that
execute other commands asynchronously (in the background).
Previously, sudo would exit immediately, causing background
commands to terminate with a broken pipe if they attempt to
write to the standard output or standard error. As of version
1.8.20, a pipe will not be used in this case so the command
will no longer be terminated.
o Upgrading from a version prior to 1.8.16:
When editing files with sudoedit, files in a directory that is
writable by the invoking user may no longer be edited by default.
Also, sudoedit will refuse to follow a symbolic link in the
path to be edited if that directory containing the link is
writable by the user. This behavior can be disabled by negating
the sudoedit_checkdir sudoers option, which is now enabled by
default.
o Upgrading from a version prior to 1.8.15:
Prior to version 1.8.15, when env_reset was enabled (the default)
and the -s option was not used, the SHELL environment variable
was set to the shell of the invoking user. In 1.8.15 and above,
when env_reset is enabled and the -s option is not used, SHELL
is set based on the target user.
When editing files with sudoedit, symbolic links will no longer
be followed by default. The old behavior can be restored by
enabling the sudoedit_follow option in sudoers or on a per-command
basis with the FOLLOW and NOFOLLOW tags.
Prior to version 1.8.15, groups listed in sudoers that were not
found in the system group database were passed to the group
plugin, if any. Starting with 1.8.15, only groups of the form
%:group are resolved via the group plugin by default. The old
behavior can be restored by using the always_query_group_plugin
sudoers option.
Locking of the time stamp file has changed in sudo 1.8.15.
Previously, the user's entire time stamp file was locked while
retrieving and updating a time stamp record. Now, only a single
record, specific to the tty or parent process ID, is locked.
This lock is held while the user enters their password. If
sudo is suspended at the password prompt (or run in the
background), the lock is dropped until sudo is resumed, at which
point it will be reacquired. This allows sudo to be used in a
pipeline even when a password is required--only one instance
of sudo will prompt for a password.
o Upgrading from a version prior to 1.8.14:
On HP-UX, sudo will no longer check for "plugin.sl" if "plugin.so"
is specified but does not exist. This was a temporary hack for
backward compatibility with Sudo 1.8.6 and below when the
plugin path name was not listed in sudo.conf. A plugin path
name that explicitly ends in ".sl" will still work as expected.
o Upgrading from a version prior to 1.8.12:
On Solaris, sudo is now able to determine the NIS domain name.
As a result, if you had previously been using netgroups that
do not include the domain, you will need to either set the
domain in the entry or leave the domain part of the tuple blank.
For example, the following will no longer work:
my-hosts (foo,-,-) (bar,-,-) (baz,-,-)
and should be changed to:
my-hosts (foo,-,) (bar,-,) (baz,-,)
o Upgrading from a version prior to 1.8.10:
The time stamp file format has changed in sudo 1.8.10. There
is now a single time stamp file for each user, even when tty-based
time stamps are used. Each time stamp file may contain multiple
records to support tty-based time stamps as well as multiple
authentication users. On systems that support it, monotonic
time is stored instead of wall clock time. As a result, it is
important that the time stamp files not persist when the system
reboots. For this reason, the default location for the time
stamp files has changed back to a directory located in /var/run.
Systems that do not have /var/run (e.g. AIX) or that do not clear
it on boot (e.g. HP-UX) will need to clear the time stamp
directory via a start up script. Such a script is installed by
default on AIX and HP-UX systems.
Because there is now a single time stamp file per user, the -K
option will remove all of the user's time stamps, not just the
time stamp for the current terminal.
Lecture status is now stored separately from the time stamps
in a separate directory: /var/db/sudo/lectured, /var/lib/sudo/lectured
or /var/adm/sudo/lectured depending on what is present on the
system.
LDAP-based sudoers now uses a default search filter of
(objectClass=sudoRole) for more efficient queries. It is
possible to disable the default search filter by specifying
SUDOERS_SEARCH_FILTER in ldap.conf but omitting a value.
o Upgrading from a version prior to 1.8.7:
Sudo now stores its libexec files in a "sudo" sub-directory
instead of in libexec itself. For backward compatibility, if
the plugin is not found in the default plugin directory, sudo
will check the parent directory default directory ends in "/sudo".
The default sudo plugins now all use the .so extension, regardless
of the extension used by system shared libraries. For backward
compatibility, sudo on HP-UX will also search for a plugin with
an .sl extension if the .so version is not found.
Handling of users belonging to a large number of groups has
changed. Previously, sudo would only use the group list from
the kernel unless the system_group plugin was enabled in sudoers.
Now, sudo will query the groups database if the user belongs
to the maximum number of groups supported by the kernel. See
the group_source and max_groups settings in the sudo.conf manual
for details.
o Upgrading from a version prior to 1.8.2:
When matching Unix groups in the sudoers file, sudo will now
match based on the name of the group as it appears in sudoers
instead of the group-ID. This can substantially reduce the
number of group lookups for sudoers files that contain a large
number of groups. There are a few side effects of this change.
1) Unix groups with different names but the same group-ID are
can no longer be used interchangeably. Sudo will look up all
of a user's groups by group-ID and use the resulting group
names when matching sudoers entries. If there are multiple
groups with the same ID, the group name returned by the
system getgrgid() library function is the name that will be
used when matching sudoers entries.
2) Unix group names specified in the sudoers file that are
longer than the system maximum will no longer match. For
instance, if there is a Unix group "fireflie" on a system
where group names are limited to eight characters, "%fireflies"
in sudoers will no longer match "fireflie". Previously, a
lookup by name of the group "fireflies" would have matched
the "fireflie" group on most systems.
The legacy group matching behavior may be restored by enabling
the match_group_by_gid Defaults option in sudoers available
in sudo 1.8.18 and higher.
o Upgrading from a version prior to 1.8.1:
Changes in the sudoers parser could result in parse errors for
existing sudoers file. These changes cause certain erroneous
entries to be flagged as errors where before they allowed.
Changes include:
Combining multiple Defaults entries with a backslash. E.g.
Defaults set_path \
Defaults syslog
which should be:
Defaults set_path
Defaults syslog
Also, double-quoted strings with a missing end-quote are now
detected and result in an error. Previously, text starting a
double quote and ending with a newline was ignored. E.g.
Defaults set_path"foo
In previous versions of sudo, the `"foo' portion would have
been ignored.
To avoid problems, sudo 1.8.1's "make install" will not install
a new sudo binary if the existing sudoers file has errors.
In Sudo 1.8.1 the "noexec" functionality has moved out of the
sudoers policy plugin and into the sudo front-end. As a result,
the path to the noexec file is now specified in the sudo.conf
file instead of the sudoers file. If you have a sudoers file
that uses the "noexec_file" option, you will need to move the
definition to the sudo.conf file instead.
Old style in /etc/sudoers:
Defaults noexec_file=/usr/local/libexec/sudo_noexec.so
New style in /etc/sudo.conf:
Path noexec /usr/local/libexec/sudo_noexec.so
o Upgrading from a version prior to 1.8.0:
Starting with version 1.8.0, sudo uses a modular framework to
support policy and I/O logging plugins. The default policy
plugin is "sudoers" which provides the traditional sudoers
evaluation and I/O logging. Plugins are typically located in
/usr/libexec or /usr/local/libexec, though this is system-dependent.
The sudoers plugin is named "sudoers.so" on most systems.
The sudo.conf file, usually stored in /etc, is used to configure
plugins. This file is optional--if no plugins are specified
in sudo.conf, the "sudoers" plugin is used. See the example
sudo.conf file in the docs directory or refer to the updated
sudo manual to see how to configure sudo.conf.
The "askpass" setting has moved from the sudoers file to the
sudo.conf file. If you have a sudoers file that uses the
"askpass" option, you will need to move the definition to the
sudo.conf file.
Old style in /etc/sudoers:
Defaults askpass=/usr/X11R6/bin/ssh-askpass
New style in /etc/sudo.conf:
Path askpass /usr/X11R6/bin/ssh-askpass
o Upgrading from a version prior to 1.7.5:
Sudo 1.7.5 includes an updated LDAP schema with support for
the sudoNotBefore, sudoNotAfter and sudoOrder attributes.
The sudoNotBefore and sudoNotAfter attribute support is only
used when the SUDOERS_TIMED setting is enabled in ldap.conf.
If enabled, those attributes are used directly when constructing
an LDAP filter. As a result, your LDAP server must have the
updated schema if you want to use sudoNotBefore and sudoNotAfter.
The sudoOrder support does not affect the LDAP filter sudo
constructs and so there is no need to explicitly enable it in
ldap.conf. If the sudoOrder attribute is not present in an
entry, a value of 0 is used. If no entries contain sudoOrder
attributes, the results are in whatever order the LDAP server
returns them, as in past versions of sudo.
Older versions of sudo will simply ignore the new attributes
if they are present in an entry. There are no compatibility
problems using the updated schema with older versions of sudo.
o Upgrading from a version prior to 1.7.4:
Starting with sudo 1.7.4, the time stamp files have moved from
/var/run/sudo to either /var/db/sudo, /var/lib/sudo or /var/adm/sudo.
The directories are checked for existence in that order. This
prevents users from receiving the sudo lecture every time the
system reboots. Time stamp files older than the boot time are
ignored on systems where it is possible to determine this.
Additionally, the tty_tickets sudoers option is now enabled by
default. To restore the old behavior (single time stamp per user),
add a line like:
Defaults !tty_tickets
to sudoers or use the --without-tty-tickets configure option.
The HOME and MAIL environment variables are now reset based on the
target user's password database entry when the env_reset sudoers option
is enabled (which is the case in the default configuration). Users
wishing to preserve the original values should use a sudoers entry like:
Defaults env_keep += HOME
to preserve the old value of HOME and
Defaults env_keep += MAIL
to preserve the old value of MAIL.
NOTE: preserving HOME has security implications since many programs
use it when searching for configuration files. Adding HOME to env_keep
may enable a user to run unrestricted commands via sudo.
The default syslog facility has changed from "local2" to "authpriv"
(or "auth" if the operating system doesn't have "authpriv").
The --with-logfac configure option can be used to change this
or it can be changed in the sudoers file.
o Upgrading from a version prior to 1.7.0:
Starting with sudo 1.7.0, comments in the sudoers file must not
have a digit or minus sign immediately after the comment character
('#'). Otherwise, the comment may be interpreted as a user or
group-ID.
When sudo is build with LDAP support the /etc/nsswitch.conf file is
now used to determine the sudoers sea ch order. sudo will default to
only using /etc/sudoers unless /etc/nsswitch.conf says otherwise.
This can be changed with an nsswitch.conf line, e.g.:
sudoers: ldap files
Would case LDAP to be searched first, then the sudoers file.
To restore the pre-1.7.0 behavior, run configure with the
--with-nsswitch=no flag.
Sudo now ignores user .ldaprc files as well as system LDAP defaults.
All LDAP configuration is now in /etc/ldap.conf (or whichever file
was specified by configure's --with-ldap-conf-file option).
If you are using TLS, you may now need to specify:
tls_checkpeer no
in sudo's ldap.conf unless ldap.conf references a valid certificate
authority file(s).
Please also see the NEWS file for a list of new features in
sudo 1.7.0.
o Upgrading from a version prior to 1.6.9:
Starting with sudo 1.6.9, if an OS supports a modular authentication
method such as PAM, it will be used by default by configure.
Environment variable handling has changed significantly in sudo
1.6.9. Prior to version 1.6.9, sudo would preserve the user's
environment, pruning out potentially dangerous variables.
Beginning with sudo 1.6.9, the environment is reset to a default
set of values with only a small number of "safe" variables
preserved. To preserve specific environment variables, add
them to the "env_keep" list in sudoers. E.g.
Defaults env_keep += "EDITOR"
The old behavior can be restored by negating the "env_reset"
option in sudoers. E.g.
Defaults !env_reset
There have also been changes to how the "env_keep" and
"env_check" options behave.
Prior to sudo 1.6.9, the TERM and PATH environment variables
would always be preserved even if the env_keep option was
redefined. That is no longer the case. Consequently, if
env_keep is set with "=" and not simply appended to (i.e. using
"+="), PATH and TERM must be explicitly included in the list
of environment variables to keep. The LOGNAME, SHELL, USER,
and USERNAME environment variables are still always set.
Additionally, the env_check setting previously had no effect
when env_reset was set (which is now on by default). Starting
with sudo 1.6.9, environment variables listed in env_check are
also preserved in the env_reset case, provided that they do not
contain a '/' or '%' character. Note that it is not necessary
to also list a variable in env_keep--having it in env_check is
sufficient.
The default lists of variables to be preserved and/or checked
are displayed when sudo is run by root with the -V flag.
o Upgrading from a version prior to 1.6.8:
Prior to sudo 1.6.8, if /var/run did not exist, sudo would put
the time stamp files in /tmp/.odus. As of sudo 1.6.8, the
time stamp files will be placed in /var/adm/sudo or /usr/adm/sudo
if there is no /var/run directory. This directory will be
created if it does not already exist.
Previously, a sudoers entry that explicitly prohibited running
a command as a certain user did not override a previous entry
allowing the same command. This has been fixed in sudo 1.6.8
such that the last match is now used (as it is documented).
Hopefully no one was depending on the previous (buggy) behavior.
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 default 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
as:
millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, \
(root) PASSWD:/bin/ls, /sbin/dump
Additionally, sudo now uses a per-user time stamp directory
instead of a time stamp file. This allows tty time stamps to
simply be files within the user's time stamp dir. For the
default, non-tty case, the time stamp on the directory itself
is used.
Also, the temporary file used by visudo is now /etc/sudoers.tmp
since some versions of vipw on systems with shadow passwords use
/etc/stmp for the temporary shadow file.
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 file system).

577
docs/UPGRADE.md Normal file
View File

@@ -0,0 +1,577 @@
Notes on upgrading from an older release
========================================
* Upgrading from a version prior to 1.9.9:
On systems where SELinux is enabled and sudo is built with
SELinux support, if the user's role is not "unconfined_r" sudo
will always execute commands via the "sesh" helper program.
Previously, commands were only executed via "sesh" if a role
was specified in the sudoers file rule or by the user on the
command line.
Sudo now runs commands with the core limit resource limit set
to 0 by default. While most operating systems restrict core
dumps of set-user-ID programs like sudo, this protection is
lost when sudo executes a command. By disabling core dumps by
default, it is possible to avoid potential security problems
such as those seen with the Linux logrotate utility, which could
interpret a core dump as a valid configuration file.
* Upgrading from a version prior to 1.9.7:
Sudo now links with OpenSSL 1.0.1 or higher by default if it
is present on the system unless it is explicitly disabled (via
`--disable-openssl`), or unless the sudo log client and server
code is disabled (via `--disable-log-client` and `--disable-log-server`).
As a result, the sudo log server (and the client built into the
sudoers plugin) now support TLS connections by default.
* Upgrading from a version prior to 1.9.3:
Due to the addition of the CHROOT and CWD options, it is no
longer possible to declare an alias with one of those names.
If a sudoers file has an alias with one of those names, sudo
and visudo will report a syntax error with a message like
"syntax error: unexpected CHROOT, expecting ALIAS".
Starting with version 1.9.3, sudoers rules must end in either
a newline or the end-of-file. This makes it possible to provide
better error messages. Previously, it was possible to include
multiple rules on a single line, separated by white space.
Starting with version 1.9.3, sudo will attempt to recover from
a syntax error in the sudoers file by discarding the portion
of the line that contains the error until the end of the line.
To restore the historic behavior of refusing to run when a
syntax error is encountered, add "error_recovery=false" as a
plugin option in sudo.conf for the "sudoers_audit" plugin, (or
"sudoers_policy" if there is no "sudoers_audit" plugin configured).
* Upgrading from a version prior to 1.9.1:
Starting with version 1.9.1, sudoers plugin arguments in sudo.conf
should be specified for the "sudoers_audit" plugin, not
"sudoers_policy". This is because the sudoers file is now
opened and parsed by the "sudoers_audit" plugin. Previously,
this was done by the "sudoers_policy" plugin. The use of an
audit plugin makes it possible for the sudoers module to detect
when a command has been rejected by an approval plugin and only
log commands that are allowed by both policy and approval
plugins.
* Upgrading from a version prior to 1.8.30:
Starting with version 1.8.30, sudo will no longer allow commands
to be run as a user or group ID that is not in the password or
group databases by default. Previously, sudo would always allow
unknown user or group IDs if the sudoers entry permitted it,
including via the "ALL" alias. The old behavior can be restored
by setting the new "allow_unknown_runas_id" Defaults setting
in the sudoers file.
* Upgrading from a version prior to 1.8.29:
Starting with version 1.8.29, if the umask is explicitly set
in sudoers, that value is used regardless of the umask specified
by PAM or login.conf. However, if the umask is not explicitly
set in sudoers, PAM or login.conf may now override the default
sudoers umask. Previously, the sudoers umask always overrode
the umask set by PAM, which was not the documented behavior.
* Upgrading from a version prior to 1.8.28:
Starting with version 1.8.28, sudo stores the signal that caused
a command to be suspended or resumed as a string in the I/O log
timing file. The version of sudoreplay included with sudo
1.8.28 can process either type of I/O log file but older versions
of sudoreplay are unable to replay the newer logs.
Starting with version 1.8.28, sudoedit honors the umask and
umask_override settings in sudoers. Previously, the user's
umask was used as-is.
* Upgrading from a version prior to 1.8.26:
Starting with version 1.8.26, sudo no long sets the USERNAME
environment variable when running commands. This is a non-standard
environment variable that was set on some older Linux systems.
Sudo still sets the LOGNAME, USER and, on AIX systems, LOGIN
environment variables.
Handling of the LOGNAME, USER (and on AIX, LOGIN) environment
variables has changed slightly in version 1.8.26. Sudo now
treats those variables as a single unit. This means that if
one variable is preserved or removed from the environment using
env_keep, env_check or env_delete, the others are too.
* Upgrading from a version prior to 1.8.23:
In sudo 1.8.23 the "sudoers2ldif" script and the "visudo -x"
functionality has been superseded by the "cvtsudoers" utility.
The cvtsudoers utility is intended to be a drop-in replacement
for "sudoers2ldif". Because it uses the same parser as sudo
and visudo, cvtsudoers can perform a more accurate conversion
than sudoers2ldif could.
To convert a sudoers file to JSON, the format option must be
specified. For example, instead of:
visudo -f sudoers_file -x output_file
one would use:
cvtsudoers -f json -o output_file sudoers_file
Note that unlike "visudo -x", "cvtsudoers" reads from the
standard input by default. Also, the base DN may be specified
on the command line, if desired, using the -b option.
* Upgrading from a version prior to 1.8.20:
Due to the addition of the TIMEOUT, NOTBEFORE and NOTAFTTER
options, it is no longer possible to declare an alias with one
of those names. If a sudoers file has an alias with one of
those names, sudo and visudo will report a syntax error with a
message like "syntax error: unexpected TIMEOUT, expecting ALIAS".
Starting with version 1.9.3, sudoers rules must end in either
Prior to version 1.8.20, when log_input, log_output or use_pty
were enabled, if any of the standard input, output or error
were not connected to a terminal, sudo would use a pipe. The
pipe allows sudo to interpose itself between the old standard
input, output or error and log the contents. Beginning with
version 1.8.20, a pipe is only used when I/O logging is enabled.
If use_pty is set without log_input or log_output, no pipe will
be used. Additionally, if log_input is set without log_output,
a pipe is only used for the standard input. Likewise, if
log_output is set without log_input, a pipe is only used for
the standard output and standard error. This results in a
noticeable change in behavior if the use_pty flag is set and no
terminal is present when running commands such as scripts that
execute other commands asynchronously (in the background).
Previously, sudo would exit immediately, causing background
commands to terminate with a broken pipe if they attempt to
write to the standard output or standard error. As of version
1.8.20, a pipe will not be used in this case so the command
will no longer be terminated.
* Upgrading from a version prior to 1.8.16:
When editing files with sudoedit, files in a directory that is
writable by the invoking user may no longer be edited by default.
Also, sudoedit will refuse to follow a symbolic link in the
path to be edited if that directory containing the link is
writable by the user. This behavior can be disabled by negating
the sudoedit_checkdir sudoers option, which is now enabled by
default.
* Upgrading from a version prior to 1.8.15:
Prior to version 1.8.15, when env_reset was enabled (the default)
and the -s option was not used, the SHELL environment variable
was set to the shell of the invoking user. In 1.8.15 and above,
when env_reset is enabled and the -s option is not used, SHELL
is set based on the target user.
When editing files with sudoedit, symbolic links will no longer
be followed by default. The old behavior can be restored by
enabling the sudoedit_follow option in sudoers or on a per-command
basis with the FOLLOW and NOFOLLOW tags.
Prior to version 1.8.15, groups listed in sudoers that were not
found in the system group database were passed to the group
plugin, if any. Starting with 1.8.15, only groups of the form
%:group are resolved via the group plugin by default. The old
behavior can be restored by using the always_query_group_plugin
sudoers option.
Locking of the time stamp file has changed in sudo 1.8.15.
Previously, the user's entire time stamp file was locked while
retrieving and updating a time stamp record. Now, only a single
record, specific to the tty or parent process ID, is locked.
This lock is held while the user enters their password. If
sudo is suspended at the password prompt (or run in the
background), the lock is dropped until sudo is resumed, at which
point it will be reacquired. This allows sudo to be used in a
pipeline even when a password is required--only one instance
of sudo will prompt for a password.
* Upgrading from a version prior to 1.8.14:
On HP-UX, sudo will no longer check for "plugin.sl" if "plugin.so"
is specified but does not exist. This was a temporary hack for
backward compatibility with Sudo 1.8.6 and below when the
plugin path name was not listed in sudo.conf. A plugin path
name that explicitly ends in ".sl" will still work as expected.
* Upgrading from a version prior to 1.8.12:
On Solaris, sudo is now able to determine the NIS domain name.
As a result, if you had previously been using netgroups that
do not include the domain, you will need to either set the
domain in the entry or leave the domain part of the tuple blank.
For example, the following will no longer work:
my-hosts (foo,-,-) (bar,-,-) (baz,-,-)
and should be changed to:
my-hosts (foo,-,) (bar,-,) (baz,-,)
* Upgrading from a version prior to 1.8.10:
The time stamp file format has changed in sudo 1.8.10. There
is now a single time stamp file for each user, even when tty-based
time stamps are used. Each time stamp file may contain multiple
records to support tty-based time stamps as well as multiple
authentication users. On systems that support it, monotonic
time is stored instead of wall clock time. As a result, it is
important that the time stamp files not persist when the system
reboots. For this reason, the default location for the time
stamp files has changed back to a directory located in /var/run.
Systems that do not have /var/run (e.g. AIX) or that do not clear
it on boot (e.g. HP-UX) will need to clear the time stamp
directory via a start up script. Such a script is installed by
default on AIX and HP-UX systems.
Because there is now a single time stamp file per user, the -K
option will remove all of the user's time stamps, not just the
time stamp for the current terminal.
Lecture status is now stored separately from the time stamps
in a separate directory: /var/db/sudo/lectured, /var/lib/sudo/lectured
or /var/adm/sudo/lectured depending on what is present on the
system.
LDAP-based sudoers now uses a default search filter of
(objectClass=sudoRole) for more efficient queries. It is
possible to disable the default search filter by specifying
SUDOERS_SEARCH_FILTER in ldap.conf but omitting a value.
* Upgrading from a version prior to 1.8.7:
Sudo now stores its libexec files in a "sudo" sub-directory
instead of in libexec itself. For backward compatibility, if
the plugin is not found in the default plugin directory, sudo
will check the parent directory default directory ends in "/sudo".
The default sudo plugins now all use the .so extension, regardless
of the extension used by system shared libraries. For backward
compatibility, sudo on HP-UX will also search for a plugin with
an .sl extension if the .so version is not found.
Handling of users belonging to a large number of groups has
changed. Previously, sudo would only use the group list from
the kernel unless the system_group plugin was enabled in sudoers.
Now, sudo will query the groups database if the user belongs
to the maximum number of groups supported by the kernel. See
the group_source and max_groups settings in the sudo.conf manual
for details.
* Upgrading from a version prior to 1.8.2:
When matching Unix groups in the sudoers file, sudo will now
match based on the name of the group as it appears in sudoers
instead of the group-ID. This can substantially reduce the
number of group lookups for sudoers files that contain a large
number of groups. There are a few side effects of this change.
1) Unix groups with different names but the same group-ID are
can no longer be used interchangeably. Sudo will look up all
of a user's groups by group-ID and use the resulting group
names when matching sudoers entries. If there are multiple
groups with the same ID, the group name returned by the
system getgrgid() library function is the name that will be
used when matching sudoers entries.
2) Unix group names specified in the sudoers file that are
longer than the system maximum will no longer match. For
instance, if there is a Unix group "fireflie" on a system
where group names are limited to eight characters, "%fireflies"
in sudoers will no longer match "fireflie". Previously, a
lookup by name of the group "fireflies" would have matched
the "fireflie" group on most systems.
The legacy group matching behavior may be restored by enabling
the match_group_by_gid Defaults option in sudoers available
in sudo 1.8.18 and higher.
* Upgrading from a version prior to 1.8.1:
Changes in the sudoers parser could result in parse errors for
existing sudoers file. These changes cause certain erroneous
entries to be flagged as errors where before they allowed.
Changes include:
Combining multiple Defaults entries with a backslash. E.g.
Defaults set_path \
Defaults syslog
which should be:
Defaults set_path
Defaults syslog
Also, double-quoted strings with a missing end-quote are now
detected and result in an error. Previously, text starting a
double quote and ending with a newline was ignored. E.g.
Defaults set_path"foo
In previous versions of sudo, the _"foo_ portion would have
been ignored.
To avoid problems, sudo 1.8.1's `make install` will not install
a new sudo binary if the existing sudoers file has errors.
In Sudo 1.8.1 the _noexec_ functionality has moved out of the
sudoers policy plugin and into the sudo front-end. As a result,
the path to the noexec file is now specified in the sudo.conf
file instead of the sudoers file. If you have a sudoers file
that uses the "noexec_file" option, you will need to move the
definition to the sudo.conf file instead.
Old style in /etc/sudoers:
Defaults noexec_file=/usr/local/libexec/sudo_noexec.so
New style in /etc/sudo.conf:
Path noexec /usr/local/libexec/sudo_noexec.so
* Upgrading from a version prior to 1.8.0:
Starting with version 1.8.0, sudo uses a modular framework to
support policy and I/O logging plugins. The default policy
plugin is "sudoers" which provides the traditional sudoers
evaluation and I/O logging. Plugins are typically located in
/usr/libexec or /usr/local/libexec, though this is system-dependent.
The sudoers plugin is named "sudoers.so" on most systems.
The sudo.conf file, usually stored in /etc, is used to configure
plugins. This file is optional--if no plugins are specified
in sudo.conf, the "sudoers" plugin is used. See the example
sudo.conf file in the docs directory or refer to the updated
sudo manual to see how to configure sudo.conf.
The "askpass" setting has moved from the sudoers file to the
sudo.conf file. If you have a sudoers file that uses the
"askpass" option, you will need to move the definition to the
sudo.conf file.
Old style in /etc/sudoers:
Defaults askpass=/usr/X11R6/bin/ssh-askpass
New style in /etc/sudo.conf:
Path askpass /usr/X11R6/bin/ssh-askpass
* Upgrading from a version prior to 1.7.5:
Sudo 1.7.5 includes an updated LDAP schema with support for
the sudoNotBefore, sudoNotAfter and sudoOrder attributes.
The sudoNotBefore and sudoNotAfter attribute support is only
used when the SUDOERS_TIMED setting is enabled in ldap.conf.
If enabled, those attributes are used directly when constructing
an LDAP filter. As a result, your LDAP server must have the
updated schema if you want to use sudoNotBefore and sudoNotAfter.
The sudoOrder support does not affect the LDAP filter sudo
constructs and so there is no need to explicitly enable it in
ldap.conf. If the sudoOrder attribute is not present in an
entry, a value of 0 is used. If no entries contain sudoOrder
attributes, the results are in whatever order the LDAP server
returns them, as in past versions of sudo.
Older versions of sudo will simply ignore the new attributes
if they are present in an entry. There are no compatibility
problems using the updated schema with older versions of sudo.
* Upgrading from a version prior to 1.7.4:
Starting with sudo 1.7.4, the time stamp files have moved from
/var/run/sudo to either /var/db/sudo, /var/lib/sudo or /var/adm/sudo.
The directories are checked for existence in that order. This
prevents users from receiving the sudo lecture every time the
system reboots. Time stamp files older than the boot time are
ignored on systems where it is possible to determine this.
Additionally, the tty_tickets sudoers option is now enabled by
default. To restore the old behavior (single time stamp per user),
add a line like:
Defaults !tty_tickets
to sudoers or use the `--without-tty-tickets` configure option.
The HOME and MAIL environment variables are now reset based on the
target user's password database entry when the env_reset sudoers option
is enabled (which is the case in the default configuration). Users
wishing to preserve the original values should use a sudoers entry like:
Defaults env_keep += HOME
to preserve the old value of HOME and
Defaults env_keep += MAIL
to preserve the old value of MAIL.
NOTE: preserving HOME has security implications since many programs
use it when searching for configuration files. Adding HOME to env_keep
may enable a user to run unrestricted commands via sudo.
The default syslog facility has changed from "local2" to "authpriv"
(or "auth" if the operating system doesn't have "authpriv").
The `--with-logfac` configure option can be used to change this
or it can be changed in the sudoers file.
* Upgrading from a version prior to 1.7.0:
Starting with sudo 1.7.0, comments in the sudoers file must not
have a digit or minus sign immediately after the comment character
('#'). Otherwise, the comment may be interpreted as a user or
group-ID.
When sudo is build with LDAP support the /etc/nsswitch.conf file is
now used to determine the sudoers sea ch order. sudo will default to
only using /etc/sudoers unless /etc/nsswitch.conf says otherwise.
This can be changed with an nsswitch.conf line, e.g.:
sudoers: ldap files
Would case LDAP to be searched first, then the sudoers file.
To restore the pre-1.7.0 behavior, run configure with the
`--with-nsswitch=no` flag.
Sudo now ignores user .ldaprc files as well as system LDAP defaults.
All LDAP configuration is now in /etc/ldap.conf (or whichever file
was specified by configure's `--with-ldap-conf-file` option).
If you are using TLS, you may now need to specify:
tls_checkpeer no
in sudo's ldap.conf unless ldap.conf references a valid certificate
authority file(s).
Please also see the NEWS file for a list of new features in
sudo 1.7.0.
* Upgrading from a version prior to 1.6.9:
Starting with sudo 1.6.9, if an OS supports a modular authentication
method such as PAM, it will be used by default by configure.
Environment variable handling has changed significantly in sudo
1.6.9. Prior to version 1.6.9, sudo would preserve the user's
environment, pruning out potentially dangerous variables.
Beginning with sudo 1.6.9, the environment is reset to a default
set of values with only a small number of "safe" variables
preserved. To preserve specific environment variables, add
them to the "env_keep" list in sudoers. E.g.
Defaults env_keep += "EDITOR"
The old behavior can be restored by negating the "env_reset"
option in sudoers. E.g.
Defaults !env_reset
There have also been changes to how the "env_keep" and
"env_check" options behave.
Prior to sudo 1.6.9, the TERM and PATH environment variables
would always be preserved even if the env_keep option was
redefined. That is no longer the case. Consequently, if
env_keep is set with "=" and not simply appended to (i.e. using
"+="), PATH and TERM must be explicitly included in the list
of environment variables to keep. The LOGNAME, SHELL, USER,
and USERNAME environment variables are still always set.
Additionally, the env_check setting previously had no effect
when env_reset was set (which is now on by default). Starting
with sudo 1.6.9, environment variables listed in env_check are
also preserved in the env_reset case, provided that they do not
contain a '/' or '%' character. Note that it is not necessary
to also list a variable in env_keep--having it in env_check is
sufficient.
The default lists of variables to be preserved and/or checked
are displayed when sudo is run by root with the -V flag.
* Upgrading from a version prior to 1.6.8:
Prior to sudo 1.6.8, if /var/run did not exist, sudo would put
the time stamp files in /tmp/.odus. As of sudo 1.6.8, the
time stamp files will be placed in /var/adm/sudo or /usr/adm/sudo
if there is no /var/run directory. This directory will be
created if it does not already exist.
Previously, a sudoers entry that explicitly prohibited running
a command as a certain user did not override a previous entry
allowing the same command. This has been fixed in sudo 1.6.8
such that the last match is now used (as it is documented).
Hopefully no one was depending on the previous (buggy) behavior.
* 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 default 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
as:
millert ALL=(daemon) NOPASSWD:/usr/bin/whoami, \
(root) PASSWD:/bin/ls, /sbin/dump
Additionally, sudo now uses a per-user time stamp directory
instead of a time stamp file. This allows tty time stamps to
simply be files within the user's time stamp dir. For the
default, non-tty case, the time stamp on the directory itself
is used.
Also, the temporary file used by visudo is now /etc/sudoers.tmp
since some versions of vipw on systems with shadow passwords use
/etc/stmp for the temporary shadow file.
* 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 file system).

4
etc/sudo-logsrvd.pp
View File

@@ -108,7 +108,7 @@ This makes it possible to have all sudo I/O logs on a central server."
pp_deb_release="$pp_rpm_release"
pp_deb_version="$pp_rpm_version"
pp_deb_section=admin
install -D -m 644 ${pp_destdir}$docdir/LICENSE ${pp_wrkdir}/${name}/usr/share/doc/${name}/copyright
install -D -m 644 ${pp_destdir}$docdir/LICENSE.md ${pp_wrkdir}/${name}/usr/share/doc/${name}/copyright
install -D -m 644 ${pp_destdir}$docdir/ChangeLog ${pp_wrkdir}/${name}/usr/share/doc/${name}/changelog
gzip -9f ${pp_wrkdir}/${name}/usr/share/doc/${name}/changelog
printf "$name ($pp_deb_version-$pp_deb_release) admin; urgency=low\n\n * see upstream changelog\n\n -- $pp_deb_maintainer `date '+%a, %d %b %Y %T %z'`\n" > ${pp_wrkdir}/${name}/usr/share/doc/${name}/changelog.Debian
@@ -145,7 +145,7 @@ This makes it possible to have all sudo I/O logs on a central server."
pp_macos_bundle_id=ws.sudo.pkg.sudo-logsrvd
pp_macos_pkg_background=${srcdir}/etc/macos-background.png
pp_macos_pkg_background_dark=${srcdir}/etc/macos-background.png
pp_macos_pkg_license=${pp_destdir}$docdir/LICENSE
pp_macos_pkg_license=${pp_destdir}$docdir/LICENSE.md
pp_macos_pkg_readme=${pp_wrkdir}/ReadMe.txt
perl -pe 'last if (/^What/i && $seen++)' ${pp_destdir}$docdir/NEWS > ${pp_wrkdir}/ReadMe.txt
%endif

4
etc/sudo-python.pp
View File

@@ -68,7 +68,7 @@
pp_deb_release="$pp_rpm_release"
pp_deb_version="$pp_rpm_version"
pp_deb_section=admin
install -D -m 644 ${pp_destdir}$docdir/LICENSE ${pp_wrkdir}/${name}/usr/share/doc/${name}/copyright
install -D -m 644 ${pp_destdir}$docdir/LICENSE.md ${pp_wrkdir}/${name}/usr/share/doc/${name}/copyright
install -D -m 644 ${pp_destdir}$docdir/ChangeLog ${pp_wrkdir}/${name}/usr/share/doc/${name}/changelog
gzip -9f ${pp_wrkdir}/${name}/usr/share/doc/${name}/changelog
printf "$name ($pp_deb_version-$pp_deb_release) admin; urgency=low\n\n * see upstream changelog\n\n -- $pp_deb_maintainer `date '+%a, %d %b %Y %T %z'`\n" > ${pp_wrkdir}/${name}/usr/share/doc/${name}/changelog.Debian
@@ -101,7 +101,7 @@
pp_macos_bundle_id=ws.sudo.pkg.sudo-python
pp_macos_pkg_background=${srcdir}/etc/macos-background.png
pp_macos_pkg_background_dark=${srcdir}/etc/macos-background.png
pp_macos_pkg_license=${pp_destdir}$docdir/LICENSE
pp_macos_pkg_license=${pp_destdir}$docdir/LICENSE.md
pp_macos_pkg_readme=${pp_wrkdir}/ReadMe.txt
perl -pe 'last if (/^What/i && $seen++)' ${pp_destdir}$docdir/NEWS > ${pp_wrkdir}/ReadMe.txt
%endif

6
etc/sudo.pp
View File

@@ -133,7 +133,7 @@ still allow people to get their work done."
pp_deb_release="$pp_rpm_release"
pp_deb_version="$pp_rpm_version"
pp_deb_section=admin
install -D -m 644 ${pp_destdir}$docdir/LICENSE ${pp_wrkdir}/${name}/usr/share/doc/${name}/copyright
install -D -m 644 ${pp_destdir}$docdir/LICENSE.md ${pp_wrkdir}/${name}/usr/share/doc/${name}/copyright
install -D -m 644 ${pp_destdir}$docdir/ChangeLog ${pp_wrkdir}/${name}/usr/share/doc/${name}/changelog
gzip -9f ${pp_wrkdir}/${name}/usr/share/doc/${name}/changelog
printf "$name ($pp_deb_version-$pp_deb_release) admin; urgency=low\n\n * see upstream changelog\n\n -- $pp_deb_maintainer `date '+%a, %d %b %Y %T %z'`\n" > ${pp_wrkdir}/${name}/usr/share/doc/${name}/changelog.Debian
@@ -302,7 +302,7 @@ still allow people to get their work done."
pp_macos_bundle_id=ws.sudo.pkg.sudo
pp_macos_pkg_background=${srcdir}/etc/macos-background.png
pp_macos_pkg_background_dark=${srcdir}/etc/macos-background.png
pp_macos_pkg_license=${pp_destdir}$docdir/LICENSE
pp_macos_pkg_license=${pp_destdir}$docdir/LICENSE.md
pp_macos_pkg_readme=${pp_wrkdir}/ReadMe.txt
perl -pe 'last if (/^What/i && $seen++)' ${pp_destdir}$docdir/NEWS > ${pp_wrkdir}/ReadMe.txt
%endif
@@ -404,7 +404,7 @@ still allow people to get their work done."
$docdir/ 0755
$docdir/** 0644
%if [deb]
$docdir/LICENSE ignore,ignore-others
$docdir/LICENSE.md ignore,ignore-others
$docdir/ChangeLog ignore,ignore-others
%endif
%if X"$exampledir" != X"$docdir/examples"