$ mail -s boss@fedorabook.com
Subject: I Quit I quit because you are a hateful, mean boss. -Jenny .
Cc:
Enter
$ rm -rf /home/jenny/*
$ exit
...(Normal output of less)...
It can be useful to configure sudo for ALL commands for users that already have the root password because it encourages good practice, especially when used without the NOPASSWD option. The benefits of this configuration are:
A user can assume root privilege from time to time only when it is necessary, operating without root privilege the majority of the time. Compared to the use of a root shell, this practice reduces the likelihood that a command will accidentally be executed with privilege.
If the user steps away from the display while a shell is open, root access is not exposed.
The user must enter a password to escalate privilege but does not have to enter the password for each individual privileged command in a series.
The act of typing sudo in front of privileged commands serves to remind the user to check the command carefully.
8.5.3. What About...
8.5.3.1. ...changing the password timeout?
By default, sudo won't prompt the user for their password as long as they have entered it successfully in the last five minutes. To change this value, add this entry to the top of the /etc/sudoers file:
Defaults timestamp_timeout= 2
The value for this timeout is expressed in minutes.
8.5.3.2. ...voluntarily giving up the password timestamp?
The user can voluntarily give up the timestamp at any time using the -k option:
$ sudo -k
This is useful if the terminal will be unattended for a while.
8.5.3.3. ...disabling the root password entirely (like a Debian or Ubuntu system)?
The Fedora community has discussed this idea and ultimately opted to keep a root password. Fedora's consolehelper PAM configuration relies on a root password, and using a root password can in some cases provide one additional obstacle to gaining superuser access.
8.5.4. Where Can I Learn More?
The manpages for sudo , sudoers , and visudo
8.6. Configuring PAM and consolehelper
Fedora uses the Pluggable Authentication Module (PAM) system to handle user authentication and identity changes. As the name implies, PAM is modular and configurable, enabling you to change the authentication (and authorization) setup on your system without programming.
8.6.1. How Do I Do That?
PAM configuration files are stored in /etc/pam.d , with one file per configured service. Each file is written in plain text and consists of at least three fields separated by spaces. The entries in these files are divided into four categories according to the first field, which identifies the module type . Possible values are:
auth
Authentication configuration (determining who is logging in).
account
Non-authentication-based access control, such as restricting activities by time of day.
password
Password changes or other authentication token updates (such as recording a new retinal scan or fingerprint).
session
Setup of the post-login session and environment.
The entries for a given module type are executed in sequence. For example, when performing authentication, the modules listed on the auth lines are executed in sequence.
The second field in each entry is called the control flag and determines the action taken when the module succeeds or fails. Possible values are:
required
The module must succeed for the module type to succeed. Regardless of whether the module fails or succeeds, processing will continue with the next line (other modules of the same module type will be executed), but at the end of all of the processing, a failure will be recorded.
requisite
The module must succeed for the module type to succeed. If it fails, processing stops immediately. If it succeeds, processing continues with the next line.
sufficient
If the module succeeds, then the module type succeeds and processing stops immediately. If it fails, processing continues with the next line.
optional
The module is executed, but the failure or success of the module is ignored.
include
In place of a module name, another configuration file is given. All of the lines of the same type from that configuration file are treated as if they were present in this configuration file.
It is also possible to use a complex expression as a control flag, but this feature is not used in the default Fedora Core configuration.
The remaining fields on the line contain the name of the module and any arguments to it (except when the control flag is include , in which case the third argument is the included file).
Here's an example. This is the content of /etc/pam.d/sshd , the configuration file for the SSH server daemon:
#%PAM-1.0
auth include system-auth
account include system-auth
password include system-auth
session include system-auth
session required pam_loginuid.so
Authentication is carried out by the first line, which includes all of the auth lines from the file /etc/pam.d/system-auth , which looks like this:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok