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

Module 16Special Permissions, Links and File LocationsExam Objective5.4 Special Directories and FilesObjective SummaryWorking with system files and librariesUnderstanding symbolic linkssetuid PermissionThe setuid PermissionThe 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 setuidA 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-xA 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-xUsing chmod with setuidThe chmod command can be used to set or remove the setuid permission, using either a symbolic or numeric methodSetting setuid where nnn is original permission mode:chmod u+s file or chmod 4nnn fileRemoving setuid where original mode is 4nnn:chmod u-s file or chmod 0nnn filesetgid PermissionThe setgid Permission on a FileThe 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 DirectoryUsing 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 setgidA 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-xA 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-xUsing chmod with setgidThe chmod command can be used to set or remove the setgid permission using either a symbolic or numeric methodSetting setgid where nnn is original permission mode:chmod g+s file or chmod 2nnn fileRemoving setgid where original mode is 2nnn:chmod g-s file or chmod 0nnn fileWorking with Sticky BitThe sticky bit PermissionThe 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 setWhen 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--TIf 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------TUsing chmod with sticky bitThe 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 dirRemoving sticky bit where original mode is 1nnn:chmod o-t dir or chmod 0nnn dirHard and Symbolic LinksHard Links and Symbolic LinksBoth 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.txta link name for the same file may be simply: ~/valuable.txtEach technique of linking (hard and soft) has advantages and disadvantagesOriginalfileHard Links vs. Symbolic LinksinodeData BlocksHardLink1SymLink1inodeData BlocksUnderstanding the FilesystemTo 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 ExampleSuppose that the /etc/passwd file has an inode number of 123The /etc directory would store a table with file names and inode numbers like: passwd 123 shadow 175 group 144 gshadow 897Hard 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 897Hard LinksEvery 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.originalThe 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 LinksTo 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.* 278772 -rw-rw-r--. 2 sysadmin sysadmin 5 Oct 25 15:53 file.hard.1 278772 -rw-rw-r--. 2 sysadmin sysadmin 5 Oct 25 15:53 file.originalNotice that the inode is the same for both files and they both have a link count of 2.Soft LinksA 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.confCreating Soft LinksCreating 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/passwdCreating a soft link does not increment the link count on the existing file.Comparing Hard and Soft LinksHard 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 LinkComparing Hard and Soft LinksHard links are difficult to see:A file with a link count greater than oneCan be found with find / -inum 123Soft links are easy to see:A link (type l) file The file name points to what it is linked toAdvantage: Soft LinkComparing Hard and Soft LinksHard links:Can not link to a directoryCan not link a file on one device or partition to a file on another device or partitionSoft links:Can link to directory filesCan cross from one device or partition to anotherAdvantage: Soft LinkUnderstanding the FilesystemFilesystem Hierarchy StandardFHS is a set of rules or guidelines that are recommended to be followed for how to organize the directories and files.Hosted at system directory is categorized: Shareable on the network for use by multiple machines or notHaving 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.ShareableNot ShareableVariable/var/lock/var/mailStatic/etc/optFilesystem Hierarchy StandardThe Filesystem Hierarchy Standard defines four hierarchies:The root (/) filesystem or top level directories:Must be able to boot, recover, restore or repair the systemMust be able to mount the other filesystems The /usr hierarchy:Contains most of the user commands under /usr/binThis static directory can be normally be sharedThe /usr/local hierarchy:The location for locally installed software The /var hierarchy:Contains variable dataThe root (/) hierarchyThe root (/) hierarchyDirectoryPurpose 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./binHolds essential binaries like the ls, cp, and rm commands; must be a part of the root filesystem. /bootHolds files necessary to boot the system such as the Linux kernel and associated configuration files./devPopulated with files that represent hardware devices and other special files, such as the /dev/null and /dev/zero files./etcContain essential host configurations files such as the /etc/hosts or /etc/passwd files.The root (/) hierarchyDirectoryPurpose of Directory/homeThe location of user home directories./libThe essential libraries to support the executable files in the /bin and /sbin directories./libEssential libraries built for a specific architecture. For example, the /lib64 directory for 64 bit AMD/Intel x86 compatible processors./mediaThe mount point for removable media mounted automatically./mntA mount point for temporarily mounting filesystems manually.The root (/) hierarchyDirectoryPurpose of Directory/optOptional third party software installation location./procA virtual filesystem for the kernel to report process and other information./rootThe home directory of the root user./sbinThe essential system binaries primarily used by the root user./sysA virtual filesystem holding information about hardware devices connected to the system./srvLocation where site specific services may be hosted.The root (/) hierarchyDirectoryPurpose of Directory/tmpDirectory where all users are allowed to create temporary files that is supposed to be cleared at boot time (but often is not)./usrSecond hierarchy of non-essential files for multi-user use. /varThe /var hierarchy contains files that change over time.The /usr hierarchyThe /usr hierarchyDirectory Purpose of Directory/usr/binBinaries for regular users, use when system is in multiuser mode./usr/includeFiles to be included to compile software from distribution./usr/libLibraries to support the executable files in the /usr/bin and /usr/sbin directories.The /usr hierarchyDirectory Purpose of Directory/usr/libNon-essential libraries built for a specific architecture. /usr/sbinSystem binaries for use by administrator in multiuser mode./usr/shareWhere software documentation and other application data is stored./usr/srcThe source code for compiling the kernel.The /usr/local hierarchyDirectory Purpose of Directory/usr/local/binLocal software binaries for regular user./usr/local/etcLocal software configuration files./usr/local/includeFiles that need to be included in order to compile local source code./usr/local/libLibrary files to support the executable files in the /usr/local/bin and /usr/local/sbin directories.The /usr/local hierarchyDirectory Purpose of Directory/usr/local/libexecLocal executable programs to be used by other programs and not directly by users./usr/local/sbinLocal binaries for system administrator use./usr/local/shareWhere local software man pages, information pages and other local application information is stored./usr/local/srcThe location where source code for software to be compiled locally is often placed.The /var hierarchyThe /var hierarchyDirectory Purpose of Directory/var/cacheFiles used for caching application data./var/logDirectory where most log files are kept./var/lockWhere lock files are kept for shared resources./var/spoolWhere spool files for printing and mail are stored./var/tmpTemporary files to be preserved between reboots.Organizing within the FHSAlthough 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 directoriesBinary directoriesSoftware application directoriesLibrary directoriesVariable data directoriesUser Home DirectoriesThe /home directory typically contains a separate directory for each user with an account on the system except for the root userThe /root directory is the preferred optional location for the home directory of the root userWithout administrator intervention, users can only create files in their home directory, the /tmp directory and the /var/tmp directory .Binary DirectoriesUser Binary DirectoriesBinary directories contain the programs (not necessarily actually all binary files) that users and administrators execute to start processes or applications runningThose whose name is "bin" are intended for ordinary users and include: /bin, /usr/bin and /usr/local/binThird-party applications may also store their executables in /usr/local/application/bin or /opt/application/binUsers may have their own "bin" in their home directory, like /home/bob/binSystem Binary DirectoriesThe 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/sbinThird-party administrative applications may also store their executables in /usr/local/application/sbin or /opt/application/sbinPATH and Binary DirectoriesIn 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 DirectoriesSoftware Application DirectoriesUnlike Windows, applications are not usually installed in a single directory like C:\Program FilesBy 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/binSoftware Application DirectoriesThe application's data may go into a subdirectory of /usr/share, /usr/lib, /opt/application or /var/libThe 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/applicationLibrary DirectoriesLibrary DirectoriesLibraries 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 DirectoriesLibrary 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 /lib64To 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 DirectoriesVariable Data DirectoriesThe /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.Variable Data DirectoriesWhile 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.