-Copyright (c) 1994-1996, 1998-2005, 2007-2011
+Copyright (c) 1994-1996, 1998-2005, 2007-2012
Todd C. Miller <Todd.Miller@courtesan.com>
Permission to use, copy, modify, and distribute this software for any
=head1 SYNOPSIS
-B<sudo> S<[B<-D> I<level>]> B<-h> | B<-K> | B<-k> | B<-V>
+B<sudo> B<-h> | B<-K> | B<-k> | B<-V>
B<sudo> B<-v> [B<-AknS>]
S<[B<-a> I<auth_type>]>
-S<[B<-D> I<level>]>
S<[B<-g> I<group name>|I<#gid>]> S<[B<-p> I<prompt>]>
S<[B<-u> I<user name>|I<#uid>]>
B<sudo> B<-l[l]> [B<-AknS>]
S<[B<-a> I<auth_type>]>
-S<[B<-D> I<level>]>
S<[B<-g> I<group name>|I<#gid>]> S<[B<-p> I<prompt>]>
S<[B<-U> I<user name>]> S<[B<-u> I<user name>|I<#uid>]> [I<command>]
B<sudo> [B<-AbEHnPS>]
S<[B<-a> I<auth_type>]>
S<[B<-C> I<fd>]>
-S<[B<-D> I<level>]>
S<[B<-c> I<class>|I<->]>
S<[B<-g> I<group name>|I<#gid>]> S<[B<-p> I<prompt>]>
S<[B<-r> I<role>]> S<[B<-t> I<type>]>
S<[B<-a> I<auth_type>]>
S<[B<-C> I<fd>]>
S<[B<-c> I<class>|I<->]>
-S<[B<-D> I<level>]>
S<[B<-g> I<group name>|I<#gid>]> S<[B<-p> I<prompt>]>
S<[B<-u> I<user name>|I<#uid>]> file ...
B<sudo> supports a plugin architecture for security policies and
input/output logging. Third parties can develop and distribute
-their own policy and I/O logging modules to work seemlessly with
+their own policy and I/O logging modules to work seamlessly with
the B<sudo> front end. The default security policy is I<sudoers>,
which is configured via the file F<@sysconfdir@/sudoers>, or via
LDAP. See the L<PLUGINS> section for more information.
as root, or the B<sudo> command must be run from a shell that is already
root. This option is only available on systems with BSD login classes.
-=item -D I<level>
-
-Enable debugging of B<sudo> plugins and B<sudo> itself. The I<level>
-may be a value from 1 through 9.
-
=item -E
The B<-E> (I<preserve> I<environment>) option indicates to the
variables with one important exception. If the I<setenv> option
is set in I<sudoers>, the command to be run has the C<SETENV> tag
set or the command matched is C<ALL>, the user may set variables
-that would overwise be forbidden. See L<sudoers(5)> for more information.
+that would otherwise be forbidden. See L<sudoers(5)> for more information.
=head1 PLUGINS
# Plugin plugin_name plugin_path
# Path askpass /path/to/askpass
# Path noexec /path/to/noexec.so
+ # Debug sudo /var/log/sudo_debug all@warn
+ # Set disable_coredump true
#
# The plugin_path is relative to @prefix@/libexec unless
# fully qualified.
=back
+=head1 DEBUG FLAGS
+
+B<sudo> versions 1.8.4 and higher support a flexible debugging
+framework that can help track down what B<sudo> is doing internally
+if there is a problem.
+
+A C<Debug> line consists of the C<Debug> keyword, followed by the
+name of the program to debug (B<sudo>, B<visudo>, B<sudoreplay>),
+the debug file name and a comma-separated list of debug flags.
+The debug flag syntax used by B<sudo> and the I<sudoers> plugin is
+I<subsystem>@I<priority> but the plugin is free to use a different
+format so long as it does not include a command C<,>.
+
+For instance:
+
+ Debug sudo /var/log/sudo_debug all@warn,plugin@info
+
+would log all debugging statements at the I<warn> level and higher
+in addition to those at the I<info> level for the plugin subsystem.
+
+Currently, only one C<Debug> entry per program is supported. The
+C<sudo> C<Debug> entry is shared by the B<sudo> front end, B<sudoedit>
+and the plugins. A future release may add support for per-plugin
+C<Debug> lines and/or support for multiple debugging files for a
+single program.
+
+The priorities used by the B<sudo> front end, in order of decreasing
+severity, are: I<crit>, I<err>, I<warn>, I<notice>, I<diag>, I<info>,
+I<trace> and I<debug>. Each priority, when specified, also includes
+all priorities higher than it. For example, a priority of I<notice>
+would include debug messages logged at I<notice> and higher.
+
+The following subsystems are used by B<sudo>:
+
+=over 10
+
+=item I<all>
+
+matches every subsystem
+
+=item I<args>
+
+command line argument processing
+
+=item I<conv>
+
+user conversation
+
+=item I<edit>
+
+sudoedit
+
+=item I<exec>
+
+command execution
+
+=item I<main>
+
+B<sudo> main function
+
+=item I<netif>
+
+network interface handling
+
+=item I<pcomm>
+
+communication with the plugin
+
+=item I<plugin>
+
+plugin configuration
+
+=item I<pty>
+
+pseudo-tty related code
+
+=item I<selinux>
+
+SELinux-specific handling
+
+=item I<util>
+
+utility functions
+
+=item I<utmp>
+
+utmp handling
+
+=back
+
=head1 RETURN VALUES
Upon successful execution of a program, the exit status from B<sudo>
give the user an effective root shell. For more information, please
see the C<PREVENTING SHELL ESCAPES> section in L<sudoers(5)>.
+To prevent the disclosure of potentially sensitive information,
+B<sudo> disables core dumps by default while it is executing (they
+are re-enabled for the command that is run). To aid in debugging
+B<sudo> crashes, you may wish to re-enable core dumps by setting
+"disable_coredump" to false in the F<@sysconfdir@/sudo.conf> file.
+
+ Set disable_coredump false
+
+Note that by default, most operating systems disable core dumps
+from setuid programs, which includes B<sudo>. To actually get a
+B<sudo> core file you may need to enable core dumps for setuid
+processes. On BSD and Linux systems this is accomplished via the
+sysctl command, on Solaris the coreadm command can be used.
+
=head1 ENVIRONMENT
B<sudo> utilizes the following environment variables. The security
=item F<@sysconfdir@/sudo.conf>
-B<sudo> plugin and path configuration
+B<sudo> front end configuration
=back
Todd C. Miller
-See the HISTORY file in the B<sudo> distribution or visit
-http://www.sudo.ws/sudo/history.html for a short history
-of B<sudo>.
+See the CONTRIBUTORS file in the B<sudo> distribution
+(http://www.sudo.ws/sudo/contributors.html) for a list of people
+who have contributed to B<sudo>.
+
+=head1 HISTORY
+
+See the HISTORY file in the B<sudo> distribution
+(http://www.sudo.ws/sudo/history.html) for a brief history of sudo.
=head1 CAVEATS
projects / debian / sudo / blobdiff