Special Permissions, Links and File Locations

Module 16
Special Permissions, Links

and File Locations
This slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses.
Copyright Network Development Group 2013.
Exam Objective
5.4 Special Directories and Files
Objective Summary
Working with system files and libraries
Understanding symbolic links
setuid Permission
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 cant be accessed normally by
no-rootThisusers.
slide deck is for LPI Academy instructors to use for lectures for LPI Academy courses.
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
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
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 users
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 anyCopyright "tty" or terminal Group 2013. on the system.
Network Development
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.
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
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
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 set, one user can't
delete another user's /tmp files.
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
This slide deck is forowner hasto useexecute
LPI Academy instructors permission,
for lectures for LPI Academy
courses.
Using chmod with sticky bit
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
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
Hard Links vs. Symbolic
Links
SymLink1
SymLink1 Originalfile
Originalfile HardLink1
HardLink1
inode
inode inode
inode
Data
Data Blocks
Blocks Data
Data Blocks
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 files contents are stored.
The inode table includes almost all information
about a file except the file name.
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
group 144
gshadow 897
Hard Link Example(cont)
A file called /etc/mypasswd that is hard linked
to /etc/passwd would also reference inode 123:
passwd 123
mypasswd123
shadow 175
group 144
gshadow 897
Hard Links
Every file has at least one hard link to it (for the
original file name).
The link count number appears between the
permissions and the user owner in a detailed
listing:
$ echo data > file.original
$ ls -li file.*
278772 -rw-rw-r--. 1 sysadmin sysadmin 5 Oct 25 15:42
file.original
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.
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:
$ ln file.original file.hard.1
$ ls -li file.*
file.hard.1
file.original
Notice that the inode is the same for both files
and they both have a link count of 2.
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
lrwxrwxrwx. 1 root root 22 Feb 15 2011 /etc/grub.conf
-> ../boot/grub/grub.conf
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:
$ ln -s /etc/passwd mypasswd
$ ls -l mypasswd
lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17
mypasswd -> /etc/passwd
Creating a soft link does not increment the link
count on the existing file.
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
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
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
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 theShareable
system directories, it is often
Not Shareable
necessary
Variable to use directories/var/mail
/var/lock below the top level.
Static /etc /opt
Filesystem Hierarchy
Standard
The Filesystem Hierarchy Standard defines four
hierarchies:
The root (/) filesystem or top level directories:
Must be able to boot, recover, restore or repair the system
Must be able to mount the other filesystems
The /usr hierarchy:
Contains most of the user commands under /usr/bin
This static directory can be normally be shared
The /usr/local hierarchy:
The location for locally installed software
The /var hierarchy:
Contains variable data
The root (/) hierarchy
Directo Purpose of Directory
ry
/ 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. Copyright Network Development Group 2013.
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.
ry
/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.
ry
/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.
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.
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.
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
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
resources.
/var/spool Where spool files for printing and mail
are stored.
/var/tmp Temporary files to be preserved
between reboots.
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
Binary directories
Software application directories
Library directories
Variable data directories
User Home Directories
The /home directory typically contains a separate
directory for each user with an account on the
system except for the root user
The /root directory is the preferred optional
location for the home directory of the root user
Without administrator intervention, users can
only create files in their home directory, the /tmp
directory and the /var/tmp directory .
Binary Directories
User Binary Directories
Binary directories contain the programs (not
necessarily actually all binary files) that users and
administrators execute to start processes or
applications running
Those whose name is "bin" are intended for
ordinary users and include: /bin, /usr/bin
and /usr/local/bin
Third-party applications may also store their
executables in /usr/local/application/bin
or /opt/application/bin
Users may have their own "bin" in their home
directory, like /home/bob/bin
System Binary Directories
The system binary directories contain programs
or applications that are intended for the
administrator (the root user).
System binary directories will have a "sbin" name
and include: /sbin, /usr/sbin and
/usr/local/sbin
Third-party administrative applications may also
store their executables in
/usr/local/application/sbin or
/opt/application/sbin
PATH and Binary Directories
In order to be able to execute a command
contained in one of the "bin" or "sbin" directories
by typing the command name only, the directory
containing the command needs to be contained
in the list of directories set in the PATH variable.
The PATH variable contents can be viewed by
using the echo $PATH command.
The PATH variable is usually customized by
modifying the ~/.bash_profile file.
To execute a command in a directory not in PATH,
type the absolute or relative path to the
command.
Application Directories
Software Application
Directories
Unlike Windows, applications are not usually
installed in a single directory like C:\Program
Files
By querying the software application package, the
file locations will be listed:
dpkg -L application (Debian-derived
distributions)
rpm -ql application (RPM based
distributions)
The executable program files may go in /usr/bin
if they originated from the distribution, otherwise
they may go in /usr/local/bin or
/opt/application/bin
Software Application
Directories
The application's data may go into a subdirectory
of /usr/share, /usr/lib, /opt/application
or /var/lib
The documentation for the application will
normally go in a subdirectory of
/usr/share/doc, /usr/share/man, or
/usr/share/info if it originated from the
distribution or else in /usr/local/share/man,
/usr/local/share/doc, /usr/local/share/info
or a subdirectory of /opt/application
Library Directories
Library Directories
Libraries are files that contain code with is shared
between multiple programs.
Using libraries saves disk space and memory as
multiple programs can share them and don't need
a separate copy.
Library file names typically end in ".so" to
indicate that they are "shared objects.
It is common for a 64 bit system to have both 64
bit and 32 bit versions of libraries.
Library Directories
Library directories will normally have a path that
ends in "lib.
The libraries to support the essential binaries
found in /bin and /sbin are located in /lib in
/lib64
To support the /usr/bin and /usr/sbin
executables, the /usr/lib and /usr/lib64
libraries are used.
For supporting applications not part of the of the
distribution the /usr/local/lib and
/opt/application/lib libraries are used.
Variable Data Directories
The /var directory and many of its subdirectories
contain files whose contents change frequently.
If your system is used as a mail server, then
/var/mail or /var/spool/mail will hold the
messages.
If your system is used as a print server, the
the /var/spool/cups directory is used to hold
the print jobs.
Depending on the activity of your system and
what level of detail it is logging, then the log files
in the /var/log directory might hold a large
amount of data.
While the log files found in /var/log may be
extremely helpful for troubleshooting problems,
they might become a problem themselves if they
fill up the filesystem.
Having services like mail and printing available
may be useful, but if they cause your system to
crash, then that can be a problem.
Mounting /var on a separate partition is often
done as a precaution to prevent activity under
/var from filling up the root filesystem and
crashing the system.

Special Permissions, Links and File Locations

Uploaded by

Copyright:

Available Formats

Special Permissions, Links and File Locations

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Special Permissions, Links and File Locations

Uploaded by

Copyright:

Available Formats

Module 16

Special Permissions, Links

A file which has setuid permission, but lacks

A file which has setgid permission, but lacks

You might also like