diff options
author | Alan Hicks <alan@lizella.net> | 2010-05-01 14:17:18 -0400 |
---|---|---|
committer | Alan Hicks <alan@lizella.net> | 2010-05-01 14:17:18 -0400 |
commit | dbca998ce52d78ce5e525e0d799adc83d580f66a (patch) | |
tree | c2a5ee10d4e488f77354f12e4c76a64615b94890 /chapter_10.xml | |
parent | 8ec49bb2c5d0fd2d3ee8dd519e783002f3c8f9ec (diff) | |
download | slackbook-dbca998ce52d78ce5e525e0d799adc83d580f66a.tar.xz |
Making room for new chapter and a few minor modifications.
Diffstat (limited to 'chapter_10.xml')
-rw-r--r-- | chapter_10.xml | 685 |
1 files changed, 323 insertions, 362 deletions
diff --git a/chapter_10.xml b/chapter_10.xml index a721dfa..a0ab4d2 100644 --- a/chapter_10.xml +++ b/chapter_10.xml @@ -3,496 +3,457 @@ "/usr/share/xml/docbook/xml-dtd-4.5/docbookx.dtd"> <chapter> -<title>Working with Filesystems</title> +<title>Filesystem Permissions</title> <section> -<title>The Filesystem Hierarchy</title> +<title>Permissions Overview</title> <para> -Slackware Linux stores all of its files and directories under a single -<filename>/</filename> directory, typically referred to as "root". This -is in stark contract to what you may be familiar with in the form of -Microsoft Windows. Different hard disk partitions, cdroms, usb flash -drives, and even floppy disks can all be mounted in directories under -<filename>/</filename>, but do not have anything like "drive letters". -The contents of these devices can be found almost anywhere, but there -are some sane defaults that Slackware sets up for you. For example, -cd-rw drives are most often found at <filename>/mnt/cd-rw</filename>. -Here are a few common directories present on nearly all Slackware Linux -installations, and what you can expect to find there. +As we've discussed, Slackware Linux is a multi-user operating system. +Because of this, its filesystems are mutli-user as well. This means +that every file or directory has a set of permissions that can grant or +deny privileges to different users. There are three basic permissions +and three sets of permissions for each file. Let's take a look at an +example file. +</para> + +<screen><prompt>darkstar:~$ </prompt><userinput>ls -l /bin/ls</userinput> +-rwxr-xr-x 1 root root 81820 2007-06-08 21:12 /bin/ls +</screen> + +<para> +Recall from chapter 4 that <application>ls</application> <arg>-l</arg> +lists the permissions for a file or +directory along with the user and group that "own" the file. In this +case, the permissions are rwxr-xr-x, the user is root and the group is +also root. The permissions section, while grouped together, is really +three seperate pieces. The first set of three letters are the +permissions granted to the user that owns the file. The second set of +three are those granted to the group owner, and the final three are +permissions for everyone else. </para> <table pgwide="0"> -<title>Filesystem Layout</title> -<tgroup cols="2"> +<title>Permissions of /bin/ls</title> +<tgroup cols="3"> <thead> - <entry>Directory</entry> - <entry>Explaination</entry> - </thead> - <tbody> - <row> - <entry>/</entry> - <entry>The root directory, under which all others exist</entry> - </row> <row> - <entry>/bin</entry> - <entry>Minimal set of binary programs for all users</entry> - </row> - <row> - <entry>/boot</entry> - <entry>The kernel, initrd, and other requirements for booting Slackware</entry> - </row> - <row> - <entry>/etc/</entry> - <entry>System configuration files</entry> - </row> - <row> - <entry>/dev</entry> - <entry>Collection of special files allowing direct access to hardware</entry> - </row> - <row> - <entry>/home</entry> - <entry>User directories where personal files and settings are stored</entry> - </row> - <row> - <entry>/media</entry> - <entry>Directory for auto-mounting features in DBUS/HAL</entry> - </row> - <row> - <entry>/mnt</entry> - <entry>Places to temporarily mount removable media</entry> - </row> - <row> - <entry>/opt</entry> - <entry>Directory where some (typicaly proprietary) software may be installed</entry> - </row> - <row> - <entry>/proc</entry> - <entry>Kernel exported filesystem for process information</entry> - </row> - <row> - <entry>/root</entry> - <entry>The root user's home directory</entry> - </row> - <row> - <entry>/sbin</entry> - <entry>Minimal set of system or superuser binaries</entry> - </row> - <row> - <entry>/srv</entry> - <entry>Site-specific data such as web pages served by this system</entry> - </row> - <row> - <entry>/sys</entry> - <entry>Special kernel implimentation details</entry> + <entry>Set</entry> + <entry>Listing</entry> + <entry>Meaning</entry> </row> + </thead> + <tbody> <row> - <entry>/tmp</entry> - <entry>Directory reserved for temporary files for all users</entry> + <entry>Owner</entry> + <entry>rwx</entry> + <entry>The owner "root" may read, write, and execute</entry> </row> <row> - <entry>/usr</entry> - <entry>All non-essential programs, libraries, and shared files</entry> + <entry>Group</entry> + <entry>r-x</entry> + <entry>The group "root" may read and execute</entry> </row> <row> - <entry>/var</entry> - <entry>Regularly changing data such as log files</entry> + <entry>Others</entry> + <entry>r-x</entry> + <entry>Everyone else may read and execute</entry> </row> </tbody> </tgroup> </table> -</section> - -<section> -<title>Local Filesystem Types</title> +<para> +The permissions are pretty self explainatory of course, at least for +files. Read, write, and execute allow you to read a file, write to it, +or execute it. But what do these permissions mean for directories? +Simply put, the read permissions grants the ability to list the +directory's contents (say with <application>ls</application>). The write +permission grants the ability to create new files in the directory as +well as delete the entire directory, even if you otherwise wouldn't be +able to delete some of the other files inside it. The execute +permission grants the ability to actually enter the directory (with the +<application>bash</application> built-in command cd for example). +</para> <para> -The Linux kernel supports a wide variety of filesystems, which allows -you to choose from a long list of features to tailor to your particular -need. Fortunately, most of the default filesystem types are adequate -for any needs you may have. Some filesystems are geared towards -particular media. For example, the iso9660 filesystem is used almost -exclusively for CD and DVD media. +Let's look at the permissions on a directory now. </para> -<section> -<title>ext2</title> +<screen><prompt>darkstar:~$ </prompt><userinput>ls -ld /home/alan</userinput> +drwxr-x--- 60 alan users 3040 2008-06-06 17:14 /home/alan/ +</screen> <para> -ext2 is the oldest filesystem included in Slackware Linux for storing -data on hard disks. Compared to other filesystems, ext2 is simplistic. -It is faster than most others for reading and writing data, but does -not include any journaling capability. This means that after a hard -crash, the filesystem must be exhaustively checked to discover and -(hopefully) fix any errors. +Here we see the permissions on my home directory and its ownership. The +directory is owned by the user alan and the group users. The user is +granted all rights (rwx), the group is granted only read and execute +permissions (r-x), and everyone else is prohibited from doing anything. </para> </section> <section> -<title>ext3</title> +<title><application>chmod</application>, +<application>chown</application>, and +<application>chgrp</application></title> + <para> -ext3 is the younger cousin of ext2. It was designed to replace ext2 in -most situations and shares much the same code-base, but adds journaling -support. In fact, ext3 and ext2 are so much alike that it is possible -to convert one to the other on the fly without lose of data. ext3 -enjoys a lot of popularity for these reasons. There are many tools -available for recovering data from this filesystem in the event of -catastrophic hardware failure as well. ext3 is a good general purpose -filesystem with journaling support, but fails to perform as well as -other journaling filesystems in specific cases. One pitfall to ext3 is -that the filesystem must still go through this exhaustive check every -so often. This is done when the filesystem is mounted, usually when the -computer is booted, and causes an annoying delay. +So now that we know what permissions are, how do we change them? And +for that matter, how do we assign user and group ownership? The answer +is right here in this section. </para> -</section> -<section> -<title>reiserfs</title> <para> -reiserfs is one of the oldest journaling filesystems for the Linux -kernel and has been supported by Slackware for many years. It is a very -fast filesystem particularly well suited for storing, retrieving, and -writing lots of small files. Unfortunately there are few tools for -recovering data should you experience a drive failure, and reiserfs -partitions experience corruption more often than ext3. +The first tool we'll discuss is the useful +<application>chown</application> +(1) command. Using <application>chown</application>, we can (you guessed +it), change the ownership of a file or +directory. <application>chown</application> is historically used only +to change the user ownership, but can change the group ownership as well. </para> -</section> -<section> -<title>XFS</title> +<screen><prompt>darkstar:~# </prompt><userinput>ls -l /tmp/foo</userinput> +total 0 +-rw-r--r-- 1 alan users 0 2008-06-06 22:29 a +-rw-r--r-- 1 alan users 0 2008-06-06 22:29 b +<prompt>darkstar:~# </prompt><userinput>chown root /tmp/foo/a</userinput> +<prompt>darkstar:~# </prompt><userinput>ls -l /tmp/foo</userinput> +total 0 +-rw-r--r-- 1 root users 0 2008-06-06 22:29 a +-rw-r--r-- 1 alan users 0 2008-06-06 22:29 b +</screen> + <para> -XFS was contributed to the Linux kernel by SGI and is one of the best -filesystems for working with large volumes and large files. XFS uses -more RAM than other filesystems, but if you need to work with large -files its performance there is well worth the penalty in memory usage. -XFS is not particularly ill-suited for desktop or laptop use, but -really shines on a server that handles medium to large size files all -day long. Like ext3, XFS is a fully journaled filesystem. +By using a colon after the user account, you may also specify a new +group account. </para> -</section> -<section> -<title>JFS</title> +<screen><prompt>darkstar:~# </prompt><userinput>chown root:root /tmp/foo/b</userinput> +<prompt>darkstar:~# </prompt><userinput> ls -l /tmp/foo</userinput> +total 0 +-rw-r--r-- 1 root users 0 2008-06-06 22:29 a +-rw-r--r-- 1 root root 0 2008-06-06 22:29 b +</screen> + <para> -JFS was contributed to the Linux kernel by IBM and is well known for -its responsiveness even under extreme conditions. It can span colossal -volumes making it particularly well-suited for Network Attached Storage -(NAS) devices. JFS's long history and thorough testing make it one of -the most reliable journaling filesystems available for Linux. +<application>chown</application> can also be used recursively to change +the ownership of all files and directories below a target directory. +The following command would change all the files under the directory +<filename>/tmp/foo</filename> to have their ownership set to root:root. </para> -</section> -<section> -<title>iso9660</title> +<screen><prompt>darkstar:~# </prompt><userinput>chown -R root:root /tmp/foo/b</userinput></screen> + <para> -iso9660 is a filesystem specifically designed for optical media such as -CDs and DVDs. Since optical disks are read-only media, the linux kernel -does not even include write support for this filesystem. In order to -create an iso9660 filesystem, you must use user-land tools like -<application>mkisofs</application>(8) or -<application>growisofs</application>(8). +Specifying a colon and a group name without a user name will simply +change the group for a file and leave the user ownership intact. </para> -</section> -<section> -<title>vfat</title> +<screen><prompt>darkstar:~# </prompt><userinput>chown :wheel /tmp/foo/a</userinput> +<prompt>darkstar:~# </prompt><userinput>ls -l /tmp/foo</userinput> +ls -l /tmp/foo +total 0 +-rw-r--r-- 1 root wheel 0 2008-06-06 22:29 a +-rw-r--r-- 1 root root 0 2008-06-06 22:29 b +</screen> + <para> -Sometimes you may need to share data between Windows and Linux -computers, but can't transfer the files over a network. Instead you -require a shared hard drive partition or a USB flash drive. The humble -vfat filesystem is the best choice here since it is supported by the -largest variety of operating systems. Unfortuantely, being a Microsoft -designed filesystem, it does not store permissions in the same way as -traditional Linux filesystems. This means that special options must be -used to allow multiple users to access data on this filesystem. +The younger brother of <application>chown</application> is the +slightly less useful <application>chgrp</application>(1). This +command works just like <application>chown</application>, except +it can only change the group +ownership of a file. Since <application>chown</application> can +already do this, why bother with +<application>chgrp</application>? The answer is simple. Many other +operating systems use a +different version of <application>chown</application> that cannot +change the group ownership, so +if you ever come across one of those, now you know how. </para> -</section> -<section> -<title>swap</title> <para> -Unlike other filesystems which hold files and directories, swap -partitions hold virtual memory. This is very useful as it prevents the -system from crashing should all your RAM be consumed. Instead, the -kernel copies portions of the RAM into swap and frees them up for other -applications to use. Think of it as adding virtual memory to your -computer, very slow virtual memory. swap is typically a fail-safe and -shouldn't be relied upon for continual use. Add more RAM to your system -if you find yourself using lots of swap. +There's a reason we discussed changing ownership before changing +permissions. The first is a much easier concept to grasp. The tool for +changing permissions on a file or directory is +<application>chmod</application>(1). The syntax for it +is nearly identical to that for <application>chown</application>, but +rather than +specify a user or group, the administrator must specify either a set of +octal permissions or a set of alphabetic permissions. Neither one is +especially easy to grasp the first time. We'll begin with the less +complicated octal permissions. </para> -</section> -</section> +<para> +Octal permissions derive their name from being assigned by one of eight +digits, namely the numbers 0 through 7. Each permissions is assigned a +number that is a power of 2, and those numbers are added together to +get the final permissions for one of the permission sets. If this +sounds confusing, maybe this table will help. +</para> -<section> -<title>Using <application>mount</application></title> +<table pgwide="0"> +<title>Octal Permissions</title> +<tgroup cols="2"> + <thead> + <row> + <entry>Permission</entry> + <entry>Meaning</entry> + </row> + </thead> + <tbody> + <row> + <entry>Read</entry> + <entry>4</entry> + </row> + <row> + <entry>Write</entry> + <entry>2</entry> + </row> + <row> + <entry>Execute</entry> + <entry>1</entry> + </row> + </tbody> +</tgroup> +</table> <para> -Now that we've learned what (some of) the different filesystems -available in Linux are, it's time we looked at how to use them. In -order to read or write data on a filesystem, that filesystem must first -be mounted. To do this, we (naturally) use -<application>mount</application>(8). The first thing we must do is -decide where we want the filesystem located. Recall that there are no -such things are drive letters denoting filesystems in Linux. Instead, -all filesystems are mounted on directories. The base filesystem on -which you install Slackware is always located at <filename>/</filename> -and others are always located in subdirectories of -<filename>/</filename>. <filename>/mnt/hd</filename> is a common place -to temporarily locate a partition, so we'll use that in our first -example. In order to mount a filesystem's contents, we must tell mount -what kind of filesystem we have, where to mount it, and any special -options to use. +By adding these values together, we can reach any number between 0 and +7 and specify all possible permission combinations. For example, to +grant both read and write privilages while denying execute, we would +use the number 6. The number 3 would grant write and execute +permissions, but deny the ability to read the file. We must specify a +number for each of the three sets when using octal permissions. It's +not possible to specify only a set of user or group permissions this +way for example. </para> -<screen><prompt>darkstar:~# </prompt><userinput>mount -t ext3 /dev/hda3 /mnt/hd -o ro</userinput> +<screen><prompt>darkstar:~# </prompt><userinput>ls -l /tmp/foo/a</userinput> +-rw-r--r-- 1 root root 0 2008-06-06 22:29 a +<prompt>darkstar:~# </prompt><userinput>chmod 750 /tmp/foo/a</userinput> +<prompt>darkstar:~# </prompt><userinput>ls -l /tmp/foo/a</userinput> +-rwxr-x--- 1 root root 0 2008-06-06 22:29 a </screen> <para> -Let's disect this. We have an ext3 filesystem located on the third -partition of the first IDE device, and we've decided to mount its -contents on the directory <filename>/mnt/hd</filename>. Additionally, -we have mounted it read-only so no changes can be made to these -contents. The <arg>-t ext3</arg> argument tells -<application>mount</application> -what type of filesystem we are using, -in this case it is ext3. This lets the kernel know which driver to use. -Often <application>mount</application> can determine this for itself, -but it never hurts to explicitly declare it. Second, we tell -<application>mount</application> -where to locate the filesystem's contents. Here we've chosen -<filename>/mnt/hd</filename>. -Finally, we must decide what options to use if any. These are declared -with the <arg>-o</arg> argument. A short-list of the most common -options follows. +<application>chmod</application> can also use letter values along with +<keycap>+</keycap> or <keycap>-</keycap> to grant or deny permissions. +While this may be easier to +remember, it's often easier to use the octal permissions. </para> <table pgwide="0"> -<title>Common mount options</title> +<title>Alphabetic Permissions</title> <tgroup cols="2"> <thead> - <entry>Option</entry> - <entry>Description</entry> + <row> + <entry>Permission</entry> + <entry>Letter Value</entry> + </row> </thead> <tbody> <row> - <entry>ro</entry> - <entry>read-only</entry> + <entry>Read</entry> + <entry>r</entry> </row> <row> - <entry>rw</entry> - <entry>read-write (default)</entry> + <entry>Write</entry> + <entry>w</entry> </row> <row> - <entry>uid</entry> - <entry>user to own the contents of the filesystem</entry> + <entry>Execute</entry> + <entry>x</entry> </row> + </tbody> +</tgroup> +</table> + +<table pgwide="0"> +<title>Alphabetic Users and Groups</title> +<tgroup cols="2"> + <thead> <row> - <entry>gid</entry> - <entry>group to own the contents of the filesystem</entry> + <entry>Accounts Affected</entry> + <entry>Letter Value</entry> </row> + </thead> + <tbody> <row> - <entry>noexec</entry> - <entry>prevent execution of any files on the filesystem</entry> + <entry>User/Owner</entry> + <entry>u</entry> </row> <row> - <entry>defaults</entry> - <entry>sane defaults for most filesystems</entry> + <entry>Group</entry> + <entry>g</entry> + </row> + <row> + <entry>Others/World</entry> + <entry>o</entry> </row> </tbody> </tgroup> </table> <para> -If this is your first Linux installation, the only options you -typically need to be concerned about are <arg>ro</arg> and -<arg>rw</arg>. The exception to this rule comes when you are dealing -with filesystems that don't handle traditional Linux permissions such -as vfat or NTFS. In those cases you'll need to use the <arg>uid</arg> -or <arg>gid</arg> options to allow non-root users access to these -filesystems. -</para> - -<screen><prompt>darkstar:~# </prompt><userinput>mount -t vfat /dev/hda4 /mnt/hd -o uid=alan</userinput> -</screen> - -<para> -But Alan, that's appalling! I don't want to have to tell mount what -filesystem or options to use everytime I load a CD. It should be easier -than that. Well thankfully, it is. The <filename>/etc/fstab</filename> -file contains all this information for filesystems that the installer -sets up for you, and you can make additions to it as well. -<filename>fstab</filename>(5) looks like a simple table containing the -device to mount along with its filesystem type and optional arguments. -Let's take a look. +To use the letter values with <application>chmod</application>, you +must specify which set to use them with, either "u" for user, "g" for +group, and "o" for all others. You must also specify whether you are +adding or removing permissions with the "+" and "-" signs. Multiple +sets can be changed at once by seperating each with a comma. </para> -<screen><prompt>darkstar:~# </prompt><userinput>cat /etc/fstab</userinput> -/dev/hda1 / reiserfs defaults 1 1 -/dev/hda2 /home reiserfs defaults 1 2 -/dev/hda3 swap swap defaults 0 0 -/dev/cdrom /mnt/cdrom auto noauto,owner,ro,users 0 0 -/dev/fd0 /mnt/floppy auto noauto,owner 0 0 -devpts /dev/pts devpts gid=5,mode=620 0 0 -proc /proc proc defaults 0 0 +<screen><prompt>darkstar:/tmp/foo# </prompt><userinput>ls -l</userinput> +total 0 +-rw-r--r-- 1 alan users 0 2008-06-06 23:37 a +-rw-r--r-- 1 alan users 0 2008-06-06 23:37 b +-rw-r--r-- 1 alan users 0 2008-06-06 23:37 c +-rw-r--r-- 1 alan users 0 2008-06-06 23:37 d +<prompt>darkstar:/tmp/foo# </prompt><userinput>chmod u+x a</userinput> +<prompt>darkstar:/tmp/foo# </prompt><userinput>chmod g+w b</userinput> +<prompt>darkstar:/tmp/foo# </prompt><userinput>chmod u+x,g+x,o-r c</userinput> +<prompt>darkstar:/tmp/foo# </prompt><userinput>chmod u+rx-w,g+r,o-r d</userinput> +<prompt>darkstar:/tmp/foo# </prompt><userinput>ls -l</userinput> +-rwxr--r-- 1 alan users 0 2008-06-06 23:37 a* +-rw-rw-r-- 1 alan users 0 2008-06-06 23:37 b +-rwxr-x--- 1 alan users 0 2008-06-06 23:37 c* +-r-xr----- 1 alan users 0 2008-06-06 23:37 d* </screen> <para> -If you have an entry in <filename>fstab</filename> for your filesystem, you -need only tell mount the device node or the mount location. -</para> - -<screen><prompt>darkstar:~# </prompt><userinput>mount /dev/cdrom</userinput> -<prompt>darkstar:~# </prompt><userinput>mount /home</userinput> -</screen> - -<para> -One final use for -<application>mount</application> -is to tell you what filesystems are currently mounted and with what -options. Simply run -<application>mount</application> -without any arguments to display these. +Which you prefer to use is entirely up to you. There are places where +one is better than the other, so a real Slacker will know both inside +out. </para> </section> <section> -<title>Network Filesystems</title> +<title>SUID, SGID, and the "Sticky" Bit</title> <para> -In addition to local filesystems, Slackware supports a number of network -filesystems as both client and server. This allows you to share data -between multiple computers transparently. We'll discuss the two most -common: NFS and SMB. +We're not quite done with permissions just yet. There are three other +"special" permissions in addition to those mentioned above. They are +SUID, SGID, and the sticky bit. When a file has one or more of these +permissions set, it behaves in special ways. The SUID and SGID +permissions change the way an application is run, while the sticky bit +restricts deletion of files. These permissions are applied with +<application>chmod</application> +like read, write, and execute, but with a twist. </para> -<section> -<title>NFS</title> - <para> -NFS is the Network File System for Linux as well as several other common -operating systems. It has modest performance but supports the full range of -permissions for Slackware. In order to use NFS as either a client or a -server, you must run the remote procedure call daemon. This is easily -accomplished by setting the <filename>/etc/rc.d/rc.rpc</filename> file -executable and telling it to start. Once it has been set executable, it -will run automatically every time you boot into Slackware. +SUID and SGID stand for "Set User ID" and "Set Group ID" respectively. +When an application with one of these bits is set, the application runs +with the user or group ownership permissions of that application +regardless of what user actually +executed it. Let's take a look at a common SUID application, the humble +<application>passwd</application> and the files it modifies. </para> -<screen><prompt>darkstar:~# </prompt><userinput>chmod +x /etc/rc.d/rc.rpc</userinput> -<prompt>darkstar:~# </prompt><userinput>/etc/rc.d/rc.rpc start</userinput> +<screen><prompt>darkstar:~# </prompt><userinput>ls -l /usr/bin/passwd \ + /etc/passwd \ + /etc/shadow</userinput> +-rw-r--r-- 1 root root 1106 2008-06-03 22:23 /etc/passwd +-rw-r----- 1 root shadow 627 2008-06-03 22:22 /etc/shadow +-rws--x--x 1 root root 34844 2008-03-24 16:11 /usr/bin/passwd* </screen> <para> -Mounting an NFS share is little different than mounting a local filesystem. -Rather than specifying a local device, you must tell mount the domain name -or IP address of the NFS server and the directory to mount with a colon -between them. +Notice the permissions on <application>passwd</application>. Instead of +an <keycap>x</keycap> in the user's execute slot, we have an +<keycap>s</keycap>. This tells us that +<application>passwd</application> is a SUID program, and when we run +it, the process will run as the user "root" rather than as the user +that actually executed it. The reason for this is readily apparent as +soon as you look at the two files it modifies. Neither +<filename>/etc/passwd</filename> nor <filename>/etc/shadow</filename> +are writeable by anyone other than root. Since users need to change +their personal information, <application>passwd</application> must be +run as root in order to modify those files. </para> -<screen><prompt>darkstar:~# </prompt><userinput>mount -t nfs darkstar.example.com:/home /home</userinput> -</screen> - <para> -Running an NFS server is a little bit different. First, you must configure -each directory to be exported in the <filename>/etc/exports</filename> -file. <filename>exports</filename>(5) contains information about what -directories will be shared, who they will be shared with, and what special -permissions to grant or deny. +So what about the sticky bit? The sticky bit restricts the ability to +move or delete files and is only ever set on directories. Non-root +users cannot move or delete any files under a directory with the sticky +bit set unless they are the owner of that file. Normally anyone with +write permission to the file can do this, but the sticky bit prevents +it for anyone but the owner (and of course, root). Let's take a look at +a common "sticky" directory. </para> -<screen> -# See exports(5) for a description. -# This file contains a list of all directories exported to other computers. -# It is used by rpc.nfsd and rpc.mountd. - -/home/backup 192.168.1.0/24(sync,rw,no_root_squash) +<screen><prompt>darkstar:~# </prompt><userinput>ls -ld /tmp</userinput> +drwxrwxrwt 1 root root 34844 2008-03-24 16:11 /tmp </screen> <para> -The first column in -<filename>exports</filename> -is a list of the files to be exported via NFS. The second column is a list -of what systems may access the export along with special permissions. You -can specify hosts via domain name, IP address, or netblock address (as I -have here). Special permissions are always a parenthetical list. For a -complete list, you'll need to read the man page. For now, the only special -option that matters is <arg>no_root_squash</arg>. Usually the root user on -an NFS client cannot read or write an exported share. Instead, the root -user is "squashed" and forced to act as the nobody user. -<arg>no_root_squash</arg> prevents this. +Naturally, being a directory for the storage of temporary files sytem +wide, <filename>/tmp</filename> needs to be readable, writeable, and +executable by anyone and everyone. Since any user is likely to have a +file or two stored here at any time, it only makes good sense to +prevent other users from deleting those files, so the sticky bit has +been set. You can see it by the presence of the <keycap>t</keycap> in +place of the <keycap>x</keycap> in the world permissions section. </para> -<para> -You'll also need to run the NFS daemon. Starting and stopping NFS server -support is done with the <filename>/etc/rc.d/rc.nfsd</filename> rc script. -Set it executable and run it just like we did for -<filename>rc.rpc</filename> and you are ready to go. -</para> - -</section> - -<section> -<title>SMB</title> - -<para> -SMB is the Windows network file-sharing protocol. Connecting to SMB shares -(commonly called samba shares) is fairly straight forward. Unfortuantely, -SMB isn't as strongly supported as NFS. Still, it offers higher performance -and connectivity with Windows computers. For these reasons, SMB is the most -common network file-sharing protocol deployed on local networks. Exporting -SMB shares from Slackware is done through the samba daemon and configured -in <filename>smb.conf</filename>(5). Unfortunately configuring samba as a -service is beyond the scope of this book. Check online for additional -documentation, and as always refer to the man page. -</para> +<table pgwide="0"> +<title>SUID, SGID, and "Sticky" Permissions</title> +<tgroup cols="3"> + <thead> + <row> + <entry>Permission Type</entry> + <entry>Octal Value</entry> + <entry>Letter Value</entry> + </row> + </thead> + <tbody> + <row> + <entry>SUID</entry> + <entry>4</entry> + <entry>s</entry> + </row> + <row> + <entry>SGID</entry> + <entry>2</entry> + <entry>s</entry> + </row> + <row> + <entry>Sticky</entry> + <entry>1</entry> + <entry>t</entry> + </row> + </tbody> +</tgroup> +</table> <para> -Thankfully mounting an SMB share is easy and works almost exactly like -mounting an NFS share. You must tell mount where to find the server and -what share you wish to access in exactly the same way. Additionally, you -must specify a username and password. +When using octal permissions, you must specify an additional leading +octal value. For example, to recreate the permission on +<filename>/tmp</filename>, we would use 1777. To recreate those +permissions on <filename>/usr/bin/passwd</filename>, we would use 4711. +Essentially, any time this leading fourth octet isn't specified, +<application>chmod</application> assumes its value to be 0. </para> -<screen><prompt>darkstar:~# </prompt><userinput>mount -t cifs //darkstar/home /home -o username=alan,password=secret</userinput> +<screen><prompt>darkstar:~# </prompt><userinput>chmod 1777 /tmp</userinput> +<prompt>darkstar:~# </prompt><userinput>chmod 4711 /usr/bin/passwd</userinput> </screen> <para> -You may be wondering why the filesystem type is cifs instead of smbfs. In -older versions of the Linux kernel, smbfs was used. This has been -deprecated in favor of the better performing and more secure general -purpose cifs driver. -</para> - -<para> -All SMB shares require the <arg>username</arg> and <arg>password</arg> -arguments. This can create a security problem if you wish to place your -samba share in fstab. You may avoid this problem by using the -<arg>credentials</arg> argument. <arg>credentials</arg> points to a file -which contains the username and password information. As long as this file -is safely guarded and readable only by root, the likelyhood that your -authentication credentials will be compromised is lessened. +Using the alphabetic permission values is slightly different. Assuming +the two files above have permissions of 0000 (no permissions at all), +here is how we would set them. </para> -<screen><prompt>darkstar:~# </prompt><userinput>echo "username=alan" > /etc/creds-home</userinput> -<prompt>darkstar:~# </prompt><userinput>echo "password=secret" >> /etc/creds-home</userinput> -<prompt>darkstar:~# </prompt><userinput>mount -t cifs //darkstar/home -o credentials=/etc/creds-home</userinput> +<screen><prompt>darkstar:~# </prompt><userinput>chmod ug+rwx,o+rwt /tmp</userinput> +<prompt>darkstar:~# </prompt><userinput>chmod u+rws,go+x /usr/bin/passwd</userinput> </screen> -</section> - - - - - - - |