summaryrefslogtreecommitdiffstats
path: root/chapter_10.xml
diff options
context:
space:
mode:
authorAlan Hicks <alan@lizella.net>2010-05-01 14:17:18 -0400
committerAlan Hicks <alan@lizella.net>2010-05-01 14:17:18 -0400
commitdbca998ce52d78ce5e525e0d799adc83d580f66a (patch)
treec2a5ee10d4e488f77354f12e4c76a64615b94890 /chapter_10.xml
parent8ec49bb2c5d0fd2d3ee8dd519e783002f3c8f9ec (diff)
downloadslackbook-dbca998ce52d78ce5e525e0d799adc83d580f66a.tar.xz
Making room for new chapter and a few minor modifications.
Diffstat (limited to 'chapter_10.xml')
-rw-r--r--chapter_10.xml685
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>
-
-
-
-
-
-
-