Download
1 / 59
610 likes | 776 Views
Module 16 Special Permissions, Links and File Locations. Exam Objective 5.4 Special Directories and Files. Objective Summary Working with system files and libraries Understanding symbolic links. setuid Permission. The setuid Permission.
E N D
Exam Objective5.4 Special Directories and Files Objective Summary • Working with system files and libraries • Understanding symbolic links
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/passwdcommand. 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
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
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.
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
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 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 diror chmod 0nnn dir
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/valuable-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 Originalfile HardLink1 SymLink1 inode inode Data Blocks 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.
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/passwdfile 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 mypasswd 123 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: $ lnfile.original file.hard.1 $ ls -li file.* 278772 -rw-rw-r--. 2sysadminsysadmin 5 Oct 25 15:53 file.hard.1 278772 -rw-rw-r--. 2sysadminsysadmin 5 Oct 25 15:53 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
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
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.
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
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/tmpdirectory .
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.
