Module Linux essentials - Module 16: Special permissions, links and file locations

Module Linux essentials - Module 16 introduce special permissions, links and file locations. After studying this chapter students should be able to: Working with system files and libraries, understanding symbolic links.

Module 16 Special Permissions, Links

and File Locations

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Exam Objective 5.4 Special Directories and Files

Objective Summary

setuid Permission

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

The setuid Permission

• The setuid permission is set on certain system utilities so that an ordinary user can execute the program as if it

was run by the root user This allows an a normal user

to perform common system administration tasks without having to do gain direct access to the root account

• An excellent example of the setuid permission in action

is the /usr/bin/passwd command When a user

executes the passwd command successfully, the

command is able to update the /etc/shadow file to set

a new password for the user This file can’t be accessed normally by no-root users

Files with setuid

• A file that has setuid permission properly set will have a lowercase "s" in the “user owner” execute position,

indicating both setuid and execute permission for the user owner are set:

-rwsr-xr-x

• A file which has setuid permission, but lacks execute

permission for the user owner will show an uppercase "S"

to highlight that the permission is not effective:

-rwSr-xr-x

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Using chmod with setuid

• The chmod command can be used to set or remove the setuid permission, using either a symbolic or numeric method

• Setting setuid where nnn is original permission mode:

– chmod u+s file or chmod 4nnn file

• Removing setuid where original mode is 4nnn:

– chmod u-s file or chmod 0nnn file

setgid Permission

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

The setgid Permission on a File

• The setgid permission used on a file is similar to setuid except that it uses group permissions When a user

executes a file that is setgid, the system runs the

command as if the user were a member of the group that owns the executable, usually granting access to

additional files

• An example of setgid permission on a file is the

/usr/bin/wall command The wall command

sends messages to other user’s terminals Since this

executable is owned by the "tty" group, when it is run it grants the user access to the files owned by the "tty"

group, which effectively allows the user to write a

message to any "tty" or terminal on the system

The setgid Permission on a

Directory

• Using setgid permission on a directory is used by

administrators to make it easier for users who are in a group to be able to share files with other users in the same group

• When setgid permission is set on a directory, any files created in that directory are automatically group owned

by the group that owns the directory

• When a new subdirectory are created in a directory that has setgid, the new subdirectory will also have setgid permission and be group owned by the group that owns the parent directory

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Files with setgid

• A file that has setuid permission properly set will have a lowercase "s" in the group owner execute column,

indicating both setgid and execute permission for the user owner is set:

-r-xr-sr-x

• A file which has setgid permission, but lacks execute

permission for the group owner will show as an

uppercase "S" to highlight that the permission is not

effective:

-r-xr-Sr-x

Using chmod with setgid

• The chmod command can be used to set or remove the setgid permission using either a symbolic or numeric method

• Setting setgid where nnn is original permission mode:

– chmod g+s file or chmod 2nnn file

• Removing setgid where original mode is 2nnn:

– chmod g-s file or chmod 0nnn file

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Working with Sticky Bit

The sticky bit Permission

• The sticky bit permission is used to prevent others

from deleting files that they do not own in a directory that is shared with others

• Normally, if a user has write permission on a directory,

then that user can delete any file in that directory,

including files that user does not own, regardless of the permissions of the file

• The classic example of a directory that normally has

the sticky bit permission is the /tmp directory This

directory is standard on all Linux systems and provides

a place were all users can store files With sticky bit

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Directories with the sticky bit set

• When the sticky bit permission is set, the letter "t" will

appear in the execute column for the others: drwxrwxrwt

• Unlike setuid and setgid, where a capital letter indicated a problem that would prevent those permissions from

working, the presence of an uppercase letter "T" does

not always mean that the sticky bit permission is not set correctly: drwxrwx T

• If either the group owner or others have execute

permission, then it is possible for the sticky bit permission

to work for those accounts

• If only the user owner has execute permission, then it is not possible for the sticky bit permission to work:

drwx -T

Using chmod with sticky bit

• The chmod command can be used to set or remove the sticky bit permission using either a symbolic or numeric method

• Setting sticky bit where nnn is original permission mode:

– chmod o+t dir or chmod 1nnn dir

• Removing sticky bit where original mode is 1nnn:

– chmod o-t dir or chmod 0nnn dir

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Hard and Symbolic Links

Hard Links and Symbolic Links

• Both hard and soft (also called symbolic) links are

useful for providing alternative names for files and

directories

• Instead of having to type a long and difficult path to a

file like:

/usr/share/doc/package/data/2013/october/10/valu able-information.txt

• …a link name for the same file may be simply:

~/valuable.txt

• Each technique of linking (hard and soft) has

advantages and disadvantages

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

inode

Data Blocks

Understanding the Filesystem

• To understand how links work, it is helpful to

understand how the filesystem keeps track of files

• For every file that is created, there is one block of data

called an inode table that stores the meta-information

of the file, such as permissions, ownerships,

timestamps and pointers to where the file’s contents are stored

• The inode table includes almost all information about

a file except the file name

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Understanding the Filesystem(cont)

• Each inode table is associated with a unique inode

number.

• The ls -i command will display the inode number for

each file

• The directory stores the names of all the files within the

directory and their associated inode number

• When access is attempted on a file, the system reads

the directory data to find the file name and then

retrieves its data by looking up the data blocks

referenced in its inode

Hard Link Example

• Suppose that the /etc/passwd file has an inode

number of 123

• The /etc directory would store a table with file names

and inode numbers like:

passwd 123 shadow 175

gshadow 897

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Hard Link Example(cont)

• A file called /etc/mypasswd that is hard linked to

/etc/passwd would also reference inode 123:

passwd 123 mypasswd 123 shadow 175

gshadow 897

• The link count will increase by one for each hard link that

is added and decrease by one for each hard link that is removed

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Creating Hard Links

• To create hard links, the ln command is used with the first argument being an existing file name and the

second argument being the new file name to link to it:

Soft Links

• A soft (symbolic) link is a file that points to another file name

• Soft links have a file type of "l“

• Soft links are similar to shortcuts in Windows

• Several soft links already exist on the system

including /etc/grub.conf:

$ ls -l /etc/grub.conf

l rwxrwxrwx 1 root root 22 Feb 15 2011 /etc/grub.conf -> /boot/grub/grub.conf

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Creating Soft Links

• Creating a soft link involves using then ln command with the -s option with the existing file as the first argument and the link file name as the second argument:

Comparing Hard and Soft Links

• Hard links have no single point of failure:

– Every file name linked to the inode is equivalent.

– As long as one hard link remains, then the inode is still

accessible.

• Soft links have a single point of failure:

– If the original file is deleted or moved, then the soft link file will

no longer be valid.

– An invalid symbolic link is said to be "dangling“.

• Advantage: Hard Link

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Comparing Hard and Soft Links

• Hard links are difficult to see:

– A file with a link count greater than one

– Can be found with find / -inum 123

• Soft links are easy to see:

– A link (type l) file

– The file name points to what it is linked to

• Advantage: Soft Link

Comparing Hard and Soft Links

• Hard links:

– Can not link to a directory

– Can not link a file on one device or partition to a file on another device or partition

• Soft links:

– Can link to directory files

– Can cross from one device or partition to another

• Advantage: Soft Link

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Understanding the Filesystem

Filesystem Hierarchy Standard

• FHS is a set of rules or guidelines that are

recommended to be followed for how to organize the directories and files

• Hosted at http://www.pathname.com/fhs

• Each system directory is categorized:

– Shareable on the network for use by multiple machines or not

– Having files that have content that changes (variable) or not

(static)

• To classify the system directories, it is often necessary

to use directories below the top level.Shareable Not Shareable

Variable /var/lock /var/mail

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

Filesystem Hierarchy Standard

• The Filesystem Hierarchy Standard defines four

hierarchies:

– The root (/) filesystem or top level directories:

– The /usr hierarchy:

– The /usr/local hierarchy:

– The /var hierarchy:

The root (/) hierarchy

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

The root (/) hierarchy

Director

y Purpose of Directory

/ The base of the structure, or root of the

filesystem, this directory unifies all directories regardless of they are local partitions, removable devices or network shares.

/bin Holds essential binaries like the ls, cp, and rm

commands; must be a part of the root filesystem /boot Holds files necessary to boot the system such as

the Linux kernel and associated configuration files.

/dev Populated with files that represent hardware

devices and other special files, such as the /dev/null and /dev/zero files.

/etc Contain essential host configurations files such

as the /etc/hosts or /etc/passwd files.

The root (/) hierarchy

Directory Purpose of Directory

/home The location of user home directories.

/lib The essential libraries to support the

executable files in the /bin and /sbin directories.

/lib<qual> Essential libraries built for a specific

architecture For example, the /lib64 directory for 64 bit AMD/Intel x86 compatible processors.

/media The mount point for removable media mounted

automatically.

/mnt A mount point for temporarily mounting

filesystems manually.

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

The root (/) hierarchy

Director

/opt Optional third party software installation location./proc A virtual filesystem for the kernel to report

process and other information

/root The home directory of the root user

/sbin The essential system binaries primarily used by

the root user

/sys A virtual filesystem holding information about

hardware devices connected to the system

/srv Location where site specific services may be

hosted

The root (/) hierarchy

Director

/tmp Directory where all users are allowed to create

temporary files that is supposed to be cleared at boot time (but often is not)

/usr Second hierarchy of non-essential files for

multi-user use

/var The /var hierarchy contains files that change

over time

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

The /usr hierarchy

The /usr hierarchy

/usr/bin Binaries for regular users, use when

system is in multiuser mode

/usr/include Files to be included to compile

software from distribution

/usr/lib Libraries to support the executable

files in the /usr/bin and /usr/sbin directories

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

The /usr hierarchy

/usr/lib<qual> Non-essential libraries built for a

specific architecture

/usr/sbin System binaries for use by

administrator in multiuser mode

/usr/share Where software documentation and

other application data is stored

/usr/src The source code for compiling the

kernel

The /usr/local hierarchy

/usr/local/bin Local software binaries for

regular user

/usr/local/etc Local software configuration

files

/usr/local/include Files that need to be included in

order to compile local source code

/usr/local/lib Library files to support the

executable files in the /usr/local/bin and /usr/local/sbin directories

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

The /usr/local hierarchy

/usr/local/libexec Local executable programs to be

used by other programs and not directly by users

/usr/local/sbin Local binaries for system

administrator use

/usr/local/share Where local software man

pages, information pages and other local application

information is stored

/usr/local/src The location where source code

for software to be compiled locally is often placed

The /var hierarchy

This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses

The /var hierarchy

/var/cache Files used for caching application data

/var/log Directory where most log files are kept

/var/lock Where lock files are kept for shared

Organizing within the FHS

• Although the Filesystem Hierarchy Standard (FHS) is

helpful for a detailed understanding of the layout of the directories used by most Linux distributions, the following describes the layout of directories in more general terms:

– User home directories