• Red Hat Enterprise Linux Training – Notes

    by  • 2017/07/05 • Tech • 0 Comments

    Notes from RHEL 7 Partner Training…

    You can access Red Hat Support via the CLI tool redhat-support-tool
    The tool gives you access to the KB, which you can search from the CLI and you can work with support tickets.

    Running sosreport will create an archive file with logs and other info that can be attached to a ticket.

    redhat-support-tool has options for attaching files, it will look for an sosreport when you first open the ticket.

    RHEL 7 has symbolic links for 4 folders in / to the same folder in /usr.
    They are:

    • /bin links to /usr/bin
    • /sbin links to /usr/sbin
    • /lib links to /usr/lib
    • /lib64 links to /usr/lib64

    cp -r is required for copying folders; -r is for recursive.

    mkdir -p creates parent directories as well.

    rmdir for removing empty directories, but rm -rf for folders with contents.

    Hard links are limited to being in the same file system; soft links/symbolic links can cross file systems.

    New user accounts automatically have a Primary Group with the same name as the username. The Primary Group owns the files created by the user.

    PolicyKit is similar to UAC in Windows. It is for GUI based apps and maintains its own configuration (independent of sudo) for what users/groups are permitted to elevate their privileges.

    SU options:

      • add - to start with a clean environment
      • add -c to run a single command

    Commands run via sudo are logged to /var/log/secure

    userdel -r deletes the user from /etc/passwd and deletes their home directory.

    Deleting a user frees up the UID, which could be re-assigned to a new user. Files owned by a UID that has been assigned to a new user keep their ownership, meaning they are now owned by a new user. This may have unintended consequences.

    To find unowned files run this command as root:
    find / -nouser -o -nogroup 2> /dev/null

    Passwords for users are stored in /etc/shadow
    They are stored salted and hashed.
    Hashing algorithm defaults to SHA-512 – this can be changed – via authconfig --passalgo – but it can only be lowered to MD5 or SHA-256, so probably not a good idea. (More bits == better!)

    Passwords are processed by adding the salt to the user provided password and re-encrypted. If the value of this process matches the stored (hashed & salted) password, then the user has provided the correct password.
    Each user has a randomly generated salt. I assume this is picked at user creation time, but could be updated when the password is changed.
    Unique salts prevents identical values for hashed passwords.

    Password aging and expiry is controlled with chage.
    Account locking is controlled with usermod -L

    Users can be assigned the “nologin” shell. This will prevent shell connections, but still allows the user to have an account. Example provided includes a mail user, where access to email is controlled via local account, but the user does not access their email from a shell session.
    nologon shell is /sbin/nologin

    sssd package provides LDAP client software dependencies.
    krb5-workstation package is useful for debuging kerberos issues and can work with kerberos tickets from the CLI.

    IPA can be used to control sudo, ssh public keys, ssh host keys, server certs, automounter maps.
    IPA server provides LDAP and Kerberos.
    IPA can create and manage domains.

    samba-winbind can be installed so the computer can join an AD Domain, authconfig can be used to configure winbind.

    realmd package can be used to join an AD Domain and configure which users are allowed to login to the RedHat computer.

    Users need to login with their fully qualified name, eg:
    IPA = [email protected]
    AD = DOMAIN\user1

    RedHat has an IPA guide here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html
    But from a quick scan I don’t know what IPA stands for.

    File Permissions
    Changing Group ownership of a file or directory – use : before the group name.
    chown :newgroup dirname

    Changing User and Group ownership of a file or directory – declare as user:group.
    chown newuser:newgroup dirname

    Restrictions:
    Only root can the user that owns a file.
    root or the current owner can change the group that owns the file, but current (non-root) user can only change the group to one that the user is a member of.

    chgrp can also be used to change group ownership; chgrp works like chown, including -R for recursive.

    Special Permissions for Files
    setuid permissions allow a file to be executed as the user that owns the file, instead of the user that calls the file.
    setgid permissions allow a file to be executed as the group that owns the file.
    When looking the the file properties (ls -l) you will see a S or an s.
    The capital S means there are no execute permissions on the file, whereas the small s means that there are execute permissions.

    setuid permissions can be set using chmod u+s filename or chmod 4700 filename and setgid permissions can be set using chmod g+s filename or chmod 2700 filename.

    Special Permissions for Directories
    When the sticky bit is enabled on a directory, it restricts who can delete files. Only root, the owner of the file or the owner of the directory that the file is in can delete the file contents.
    sticky bit is displayed as a t at the end of the permissions for a directory. (ls -ld will show something like: drwxrwxrwt)
    The sticky bit is set via:
    chmod a+t directoryname or chmod 1777 directoryname

    Shared folders can be configured with setgid so that the files created in these folders inherit the group owner value that is assigned to the directory, instead of the defualt behaviour, which is to have the primary group of the user that creates the file.
    chmod g+s directoryname
    Directory permissions will show an S or an s where the x should be.
    Capital S for no execute bit on the folder.

    About

    Clint McGuire is a Computer Consultant based out of Vancouver Canada. He specializes in VMware and Storage.

    Leave a Reply

    Your email address will not be published. Required fields are marked *