Linux Training : g. Users & Groups

  • root, process accounts, normal users and oddballs

    Linux systems uses different types of users to do different things. In short there are normal users, system process users and root. Additionally there are groups that users belong to. Internally, the system keeps track of users and groups using numbers but then translates that number into a name for human ease of use. The command vipw is best for editing the /etc/passwd file as it locks the file for writing and also prompts for editing the /etc/shadow file. The command vigr will do the same thing for /etc/groups and /etc/gshadow.
    • The root user is all powerful and can change the system in ways that will break or destroy it. System administrators often have to do things as the root user. For this reason, the root user password is most often very, very long and cryptographically hard to break. If someone gains root access, they can do anything (mostly) and that's a nightmare to clean up from. The root user has UID 0 (User ID 0). If looking at /etc/passwd you see a username with the third field of 0, that user has full root access (the fields in /etc/passwd are separated by a : ).

      (lightbulb) Take look at /etc/passwd

      cat /etc/passwd

      and see if there is a user other than root with UID 0

      The fields in /etc/passwd are user name:x means using shadow passwords: user ID: group ID: home directory: default shell environment.
    • System process users are special users that exist to run certain processes on the system like web servers, tomcat services, and mail (among others). System users will have a UID between 1 and 499 on RHEL system.
    • Normal users are typically humans who will login to use the system. Normal user accounts have a UID from 500 to 4294967293. Many times a large application may have multiple user accounts in this same range. Oracle does this as well as WebSphere and SAP.
    • oddball accounts are specifically the nfsnobody account with UID 4294967294. This is a security account used to prevent NFS processes from having as many security issues as they did in years past.
  • Groups

    Linux systems have groups that can be populated with real users, system accounts or both. Users can be members of more than one group. However, groups can not be members of other groups.
    RedHat systems by default use a "every user has their own group" mentality. A new user named fred will have group created also called fred that user fred is a member of. This group fred is the default group for user fred. At GTRI, we use LIN:LDAP for user authentication and thus we also have network based user control. So all normal users are created in the users group instead of their own group.
    This is all used so that a group member can read or write a file owned by another user as long as the group has rw permissions on that file. Typically, if a shared directory is available to a group, the owner of the directory can create new files but group members can't. It is usually required to have setGID=on for the shared directory so new files are automatically group owned and not user group owned. For group members to be able to ls in a directory, the directory must be set with execute turn on for the directory itself.
  • rwx 640 and other cryptic reasons why you can't write files there

    For every file and directory there is a 3x3 of permissions. The ability to read, write and execute is divided between user, group, and everyone. So a file that is only readable by its owner will look like
    ls -la test
    -r-------- 1 jkinney9 users 4306 Apr 19 15:12 test
    
    That long line of dashes are the place holders for the permissions that have been removed. The very first dash is special. It designates a directory (d) or a special file like a socket (s) or a symlink (l). The next 3 spaces are for user permissions of read (r), write (w) and execute (x). So a file that is rwx for a user only will look like
    -rwx------ 1 jkinney9 users 4306 Apr 19 15:12 test
    
    The next three places are for group and the last three for everyone with both using the same rwx as the user section.
    Changing permissions is done using chmod. A file owner can change the owner, group and world permissions of a file. However a group member can't change the permissions of a file unless they are also the owner.

    OK. There's actually another reason besides just the file or directory permissions.
    SELinux is a very powerful security enhancement tool that runs all the time and can block access to files and directories using a rich set of rules.

    • chmod methods
      chmod is used to change permissions on a file or directory. There are two ways to do it.
  1. Using symbolic mode
    • chmod g+w to add group write
    • chmod a-r to remove all read
    • chmod u+S to set the setuid bit to true
  2. Using numeric mode
    • chmod 755 to grant everything to the owner, read and execute to group and all.
      1. Numeric mode uses octal bits 0,1,2 and 4 and sums them for each section.
      2. If there are only 3 numbers, the fourth number (at the beginning, actually) is set to 0. This number is for setuid/setgid/stickybit operations (values 4, 2 and 1 respectively)
    • chown and chgrp
      chown is used to change owner and chgrp is to change group for a file or directory.
Ownership and permissions exercise

(question)
A new functions directory called "functions" needs to contain files that will be read/execute by the app_user group and owned by the user apps in the new location /opt/newapp. All the files in the apps directory must be run as the user apps. Set up this directory assuming only /opt is existing. Create the following script called "testme.sh" that echos it's name and the name and group(s) of the user that called it.

#!/bin/sh
echo $0 $USER $(/usr/bin/groups)

LIN:page top

Users, groups and chmod

A new functions directory needs to contain files that will be read/execute by the app_user group and owned by the user apps in the new location /opt/newapp/. All the files in the apps directory must be run as the user apps. Set up this directory assuming only /opt is existing. Create the following script called "testme.sh" that echos it's name and the name and group(s) of the user that called it.

#!/bin/sh
echo $0 $USER $(/usr/bin/groups)

Commands to create and set permissions on the new directories are:

mkdir -p /opt/newapp/functions

At this point, create the script file /opt/newapp/functions/testme.sh

chown -R apps /opt/newapp
chgrp -R app_user /opt/newapp/functions
chmod u+s -R /opt/newapp/functions
chmod g+X  -R /opt/newapp
chmod g+rx /opt/newapp/functions/*

Some ls work should show:

ls -la /opt/newapp/functions/
total 24
drwsr-xr-x 2 apps app_user 4096 May  3 14:41 .
drwxr-xr-x 3 apps root     4096 May  3 13:56 ..
-rwSr-xr-- 1 apps app_user   70 May  3 14:41 testme.sh

LIN:page top