adding username to sudoers file

[Matt26]

i tried opening a system file using the sudo command and got this message:

username is not in the sudoers file. This incident will be reported.

how do i add this username to the sudoers file?

thanks.

[roundboy]

Hi Matt

Enter:
su -
{your superuser password}

Then enter:
/usr/sbin/visudo
which allows you to edit /etc/sudoers file.

Then, find the following line:
root ALL=(ALL) ALL

Add your login so it looks like (for login "jdoe"):
jdoe ALL=(ALL) ALL

This will give you all the same access as user root. So beware. There are a lot of other things you can do in Linux to lock down sudo access. I am writing up MY instructions today, I will try to post later.

[Theodor009]

change to the root user

su -

as root run

visudo

this is specifially for editing the sudo file. Protects you from making a mistake in this file which could cause root not to be able to log in.

add your user just below the root user entry

that is all there is to it.

[Dangermouse]

or if you dont want to manually edit files autoten will do it for you
http://dnmouse.org/autoten.html
http://dnmouse.org/sudo.html

[roundboy]

How to configure su and sudo Access (Part I of II)

There are the following ways that user jdoe, acting as a normal user, can execute commands requiring superuser privileges:

• Log out of the desktop session, and log back in as user root, which is a VERY bad idea.
• Enter “su -” and entering the superuser password.
  Requires that you know the superuser's password.
  Will allow user jdoe to switch to the user root account. Once switched to user root’s account, user jdoe can execute any command as the superuser until the “exit” command is executed. Convenient when user jdoe needs to enter more than one command as the superuser.
• su -c {command}
  Requires that you know the superuser's password.
  Will allow user jdoe to execute the single {command} as the superuser. This sequence needs to be entered each time a command requiring superuser privileges is typed, so it is not very convenient if more than one command requiring superuser privileges needs to be executed.
• sudo {command}
  Requires that user jdoe be configured in the /etc/sudoers file, which can only be done by someone with superuser privileges (one of the things that justifies System Administrators, at least until we know what they know).
  The /etc/sudoers file can be configured (using the visudo command) to limit the commands that user jdoe can execute using sudo, for security purposes.
  Ask the System Administrator to modify the /etc/sudoers file to add privileged commands that you run often. The idea is to keep user root’s (a.k.a., the superuser) password from all but the System Administrator.
  Once configured, user jdoe enters jdoe’s password (NOT the superuser password). For a period of about 5 minutes, user jdoe may execute commands normally requiring superuser privileges without being prompted for a password.
  
  In the event that user root’s password does get out, it will not do a user any good, as we are going to lock down the use of the su command, forcing users to be in the “wheel” group before they may execute the su command. Only trusted users will be placed in the wheel group.
  
  Each time the user issues a sudo command, this is logged. Each time a sudo command request fails, an e-mail is sent to the System Administrator. So, if a user attempts to execute commands with sudo that the user is not configured to execute, the System Administrator will know about it.

Lock down su command
To lock down the su command, we will require all users with access to the su command to be members of the wheel group. When Fedora 11 is installed out-of-the-box, the wheel group is not configured with any users other than user root.

Enter as follows to add user jdoe, to the wheel group:

[jdoe@Eng-Lab-004 ~]$ su -
Password: {user root’s password}
[root@Eng-Lab-010 ~]# gpasswd -a jdoe wheel
Adding user jdoe to group wheel
[root@Eng-Lab-010 ~]#

The /etc/pam.d/su file manages the configuration of the su command.
Enter as follows to edit the /etc/pam.d/su file (after first making a backup copy):

[root@Eng-Lab-010 ~]# cp -a /etc/pam.d/su /etc/pam.d/su.orig
[root@Eng-Lab-010 ~]# vim /etc/pam.d/su

and modify from:

#%PAM-1.0
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth           required        pam_wheel.so use_uid
auth            include         system-auth
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         optional        pam_xauth.so

to:

#%PAM-1.0
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
auth            required        pam_wheel.so use_uid
auth            include         system-auth
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         optional        pam_xauth.so

Save and close the file.
This will force users to be in the wheel group before they may execute the su command.
Log out.
Log back in as user jdoe.
Users not a member of the “wheel” group will receive the following response whenever they attempt to use the su command, even if they know user root’s password:

[jsmith@Eng-Lab-004 ~]$ su -
Password: {user root’s password}
su: incorrect password
[jsmith@Eng-Lab-004 ~]$

Configure /etc/sudoers for user jdoe
Enter as follows to configure the /etc/sudoers file to allow user jdoe permission to execute any command in the /usr/bin/ and /bin directories on hosts Eng-Lab-003, Eng-Lab-004, and Eng-Lab-005 (i.e., the local computer’s in jdoe’s subnet).

Display the compiled-in defaults for sudo
Enter as follows to display the compiled-in defaults for sudo.

[jdoe@Eng-Lab-004 ~]$ su -
Password: {user root’s password}
[root@Eng-Lab-004 pam.d]# sudo -V
    .
    .  LOTS of output
    .
[root@Eng-Lab-004 pam.d]#

Note that:

• If the user is not in the sudoers file, and issues the sudo command, an e-mail is sent to the System Administrator.
• The first time the user runs the sudo command, they get a “lecture” on the “proper” use of the sudo command.
• Once the user has issued the sudo command and entered the user’s password, future use of the sudo command does not require inputting the password for 5 minutes.
• All e-mail sent by sudo is sent to user root (i.e., the System Administrator). This can be redirected by editing /etc/aliases and running newaliases.
• /bin/vi is the default editor used by the visudo application.

Add user jdoe to the /etc/sudoers file
The following is an example /etc/sudoers file that we have found works in the Lab. It may be customized by the Project’s System Administrator to meet Project specific goals. For instance, once more users have been added to this computer, these users may be added to the User_Alias line.
NOTE: You should understand the following before using or changing, as this is what I use in the Lab, you will likely have different requirements.
Launch /usr/sbin/visudo, and add the following to the /etc/sudoers file at the indicated points:

[root@Eng-Lab-004 ~]# visudo
.
.
.
# Host alias specification
Host_Alias        LAB = Eng-Lab-003, Eng-Lab-004, Eng-Lab-005, Eng-Lab-010
.
.
.
# User alias specification
User_Alias        TRUSTED = jdoe, jsmith
.
.
.
# Cmnd alias specification
Cmnd_Alias        ADMIN = /bin/,\
                          !/bin/su,\
                          /usr/bin/,\
                          /usr/sbin/groupadd,\
                          /usr/sbin/alternatives
.
.
.
# Defaults specification
Defaults:TRUSTED         insults
Defaults@LAB             log_year, logfile=/var/log/sudo.log 
.
.
.        
# User privilege specification
root    ALL=(ALL) ALL
TRUSTED    LAB = (ALL) ADMIN

# Uncomment to allow people in group wheel to run all commands
# %wheel        ALL=(ALL)       ALL                             ⇐= NOTE: Don’t uncomment

# Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL                   ⇐= NOTE: Don’t uncomment
.
.
.

Save and close the /etc/sudoers file (i.e., press the Esc key, enter “:”, then type “wq” and press ENTER).
No need to log out and back in, the /etc/sudoers file is immediately available. Just exit from the superuser, as follows:

[root@Eng-Lab-004 ~]# exit
[jdoe@Eng-Lab-004 ~]$

See next post for PartII

[roundboy]

How to configure su and sudo Access (Part II of II)

Test user jdoe's sudo functionality
As configured above, TRUSTED users may execute commands in the following directories:

• /bin – essential commands
• /usr/bin – secondary directory, holding most of Fedora 11 application executables.

sudo su -
Note that TRUSTED users can’t circumvent the system to become the superuser by using sudo to pass the “su -” command. This would have prompted the user for the user’s password, not root’s password, but still given the user superuser permissions. Enter as follows to confirm that user jdoe can not circumvent entering user root’s password when acquiring superuser permissions:

[jdoe@Eng-Lab-004]$ sudo su -
Password: {user jdoe’s password}
Sorry, user jdoe is not allowed to execute '/bin/su -' as root on Eng-Lab-010.
[jdoe@Eng-Lab-004 ~]$

Note: This behaviour is because of the “!/bin/su” entry in the /etc/sudoers file. This prevents anyone, including user jdoe, as the System Administrator, from using sudo to run the su command.

sudo ls -la /root
Note that the “ls” executable is in the /bin/ directory. The following tests if user jdoe can access executables in the /bin directory with sudo.
Enter as follows to display user root’s directory (should fail, requires superuser privilege):

[jdoe@Eng-Lab-004 ~] ls -la /root
ls: cannot open directory /root: Permission denied

User jdoe can’t list user root’s directory, user jdoe doesn’t have the directory permissions. Now, execute the same command using sudo:

[jdoe@Eng-Lab-004 ~]$ sudo ls -la /root

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Password: {user jdoe’s password}
   .
   . LOTS of directory entries
   .
[jdoe@Eng-Lab-004 ~]$

It worked, so we can expect to execute any of the commands in the /bin directory.
Note the “lecture” on the responsibilities of using sudo.

Implicitly prevented sudoers
As configured above, executables in a directory not explicitly included in the sudoers file’s Cmnd_Alias list can not be invoked using sudo.
For example, the /usr/sbin directory is not included in the TRUSTED users accesses. Thus, /usr/sbin/visudo can not be executed by user jdoe without having root’s password.
User jdoe tries to invoke /usr/sbin/visudo from the command-line:

[jdoe@Eng-Lab-004 ~]$ visudo
visudo: /etc/sudoers: Permission denied
[jdoe@Eng-Lab-004 ~]$ /usr/sbin/visudo
visudo: /etc/sudoers: Permission denied
[jdoe@Eng-Lab-004 ~]$

Now, try with sudo:

[jdoe@Eng-Lab-004 ~]$ sudo /usr/sbin/visudo
Password: {user jdoe’s password}
Sorry, user jdoe is not allowed to execute '/usr/sbin/visudo' as root on Eng-Lab-004.
[jdoe@Eng-Lab-004 ~]$

The only way to launch an executable in /usr/sbin is to “su -” to a login shell with user root permissions, or to explicitly include in the sudoers Cmnd_Alias list the explicit commands that you want the TRUSTED users to be able to execute. For example, in our example /etc/sudoers file, we have included the “/usr/sbin/groupadd”, and “/usr/sbin/alternatives” executables, which we anticipate TRUSTED users wanting to use.
Add to the /etc/sudoers file as needed to execute additional privileged commands.