ch01_23.htm

the unix power tools

>File access is based on a file's user and group ownership and a set of
access bits (commonly called the <EM
CLASS="emphasis"
>mode bits</EM
>). When you try to
access a file, you are put into one of three classes. You are either
the file's owner, a member of the file's group, or an &quot;other.&quot;
Three bits then determine whether you are allowed to read, write, or
execute the file.
So, as
<A
CLASS="xref"
HREF="ch01_23.htm#UPT-ART-1026-FIG-0"
TITLE="Filesystem Permission Bits"
>Figure 1.5</A
>
shows, there are a total of nine mode bits (three for
each class) that set the basic access permissions.</P
><H4
CLASS="figure"
><A
CLASS="title"
NAME="UPT-ART-1026-FIG-0"
>Figure 1.5: Filesystem Permission Bits</A
></H4
><IMG
CLASS="graphic"
SRC="figs/1026a.gif"
ALT="Figure 1.5"><P
CLASS="para"
>It is common to see these nine basic mode bits interpreted as an octal
(base-8) number, in which each digit specifies the access permitted
for one class.
Each three bits makes one octal digit.
<A
CLASS="xref"
HREF="ch01_23.htm#UPT-ART-1026-FIG-1"
TITLE="Changing Permission Bits to an Octal Number"
>Figure 1.6</A
>
shows how to do it.</P
><H4
CLASS="figure"
><A
CLASS="title"
NAME="UPT-ART-1026-FIG-1"
>Figure 1.6: Changing Permission Bits to an Octal Number</A
></H4
><IMG
CLASS="graphic"
SRC="figs/1026b.gif"
ALT="Figure 1.6"><P
CLASS="para"
>Let's turn the mode bits 111101001 into an octal number.
Break it into chunks of three bits: 111 101 001. The first group, 111,
is 4+2+1 or 7. The second group, 101, 
is 4+0+1 or 5. The third group,
001, is 0+0+1 or 1. So those mode bits can be written as the octal number 751.</P
><P
CLASS="para"
>To tie this together, look at
<A
CLASS="xref"
HREF="ch01_23.htm#UPT-ART-1026-FIG-0"
TITLE="Filesystem Permission Bits"
>Figure 1.5</A
>
again-and work out these examples yourself.
For example, if the owner of a file has read and write access,
but no one else is allowed to touch the file, we say that it has the
access mode 600. A file that is readable, writable, and executable
by everyone has access mode 777. A file that is readable and
writable by everyone (i.e., a public text file) has mode 666.</P
><P
CLASS="para"
>It is also common to see the mode bits expressed as a sequence of
ten alphabetic characters (look at the listing from
<SPAN
CLASS="link"
><EM
CLASS="emphasis"
>ls -l</EM
> (<A
CLASS="linkend"
HREF="ch22_02.htm"
TITLE="Tutorial on File and Directory Permissions "
>22.2</A
>)</SPAN
>).
The first character tells you the file's type. For a plain file, this
character is a <CODE
CLASS="literal"
>-</CODE
>. For a directory, it's a <CODE
CLASS="literal"
>d</CODE
>. The
next three bits report the owner's access, the middle three bits
report group access, and the final three bits report access for others.
An <CODE
CLASS="literal"
>r</CODE
> indicates that read access is allowed, <CODE
CLASS="literal"
>w</CODE
> indicates
that write access is allowed, and <CODE
CLASS="literal"
>x</CODE
> indicates that execute
access is allowed. For example:</P
><P
CLASS="para"
><BLOCKQUOTE
CLASS="screen"
><PRE
CLASS="screen"
>-rw-------<I
CLASS="lineannotation"
>is mode 600</I
>
-rwxrwxrwx<I
CLASS="lineannotation"
>is mode 777</I
>
-rw-rw-rw-<I
CLASS="lineannotation"
>is mode 666</I
></PRE
></BLOCKQUOTE
></P
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-2201"
></A
><A
CLASS="indexterm"
NAME="AUTOID-2202"
></A
>You can change a string like <CODE
CLASS="literal"
>rw-rw-rw-</CODE
> into an octal number
with the technique in
<A
CLASS="xref"
HREF="ch01_23.htm#UPT-ART-1026-FIG-1"
TITLE="Changing Permission Bits to an Octal Number"
>Figure 1.6</A
>
Split it into three-bit chunks.
For example, <CODE
CLASS="literal"
>rw-</CODE
> would have the value 4+2+0-that's 6.
Therefore, <CODE
CLASS="literal"
>rw-rw-rw-</CODE
> is 666 octal.</P
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-2209"
></A
>If the file is executable, a few other bits come into play. One is
the &quot;sticky bit,&quot; which tells UNIX to leave the executable in memory
after the program has finished running. In theory, leaving the
executable around reduces the program's startup time for subsequent
users. The sticky bit was an
interesting idea a long time ago, but it is obsolete now: modern
virtual memory techniques like demand paging have made it
unnecessary. Many UNIX users and UNIX books still believe
that the sticky bit does something important, so you will hear it
mentioned from time to time.</P
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-2212"
></A
><A
CLASS="indexterm"
NAME="AUTOID-2214"
></A
><A
CLASS="indexterm"
NAME="AUTOID-2216"
></A
><A
CLASS="indexterm"
NAME="AUTOID-2219"
></A
>More important are the &quot;set user ID&quot; and &quot;set group ID&quot; (SUID and
SGID) bits. If you execute an SUID file, your user ID is set to the
user ID of the file's owner. Therefore, if you execute an SUID file
that is owned by root, you are the superuser-for the duration
of the program. Likewise, executing an SGID file sets your group ID to
the file's group while the file is executing. SUID and SGID files can
be security holes, but they really exist to enhance security. For
example, you might want to allow any user to create a backup tape,
but you shouldn't give every user the root password. Therefore, you<A
CLASS="indexterm"
NAME="AUTOID-2222"
></A
><A
CLASS="indexterm"
NAME="AUTOID-2225"
></A
><A
CLASS="indexterm"
NAME="AUTOID-2228"
></A
>
can create a special version of the <EM
CLASS="emphasis"
>dump</EM
> utility that is owned
by root and that has the SUID bit set. When a user invokes this
utility, he or she will be able to back up the entire filesystem
because the <EM
CLASS="emphasis"
>dump</EM
> command will run as if it were executed by
root. But the user can't do anything else: he doesn't know the
superuser password and can't do anything that <EM
CLASS="emphasis"
>dump</EM
> won't let him
do. Used carefully, SUID programs can be a powerful administrative tool.

<BLOCKQUOTE
CLASS="note"
><P
CLASS="para"
><STRONG
>NOTE:</STRONG
> SUID and SGID programs are such major security holes that many
conscientious administrators refuse to add new SUID utilities.
Some versions of UNIX ignore the SUID and
SGID bits for shell scripts (command files)-on those versions, only compiled
programs
can be SUID or SGID. SUID and SGID programs always lose
their special properties when they are copied. However, making
SUID and SGID programs completely safe is very difficult (or
maybe impossible). For better or for
worse, a lot of standard UNIX utilities (<EM
CLASS="emphasis"
>uucp</EM
> and <EM
CLASS="emphasis"
>lpr</EM
>, for
example) are SUID.<A
CLASS="indexterm"
NAME="AUTOID-2237"
></A
><A
CLASS="indexterm"
NAME="AUTOID-2238"
></A
><A
CLASS="indexterm"
NAME="AUTOID-2239"
></A
><A
CLASS="indexterm"
NAME="AUTOID-2240"
></A
>
Article
<A
CLASS="xref"
HREF="ch22_01.htm#UPT-ART-5010"
TITLE="Introduction to File Ownership and Security "
>22.1</A
>
introduces other information about file access permissions.</P
></BLOCKQUOTE
></P
><DIV
CLASS="sect1info"
><P
CLASS="SECT1INFO"
>- <SPAN
CLASS="authorinitials"
>ML</SPAN
></P
></DIV
></DIV
><DIV
CLASS="htmlnav"
><P
></P
><HR
ALIGN="LEFT"
WIDTH="515"
TITLE="footer"><TABLE
WIDTH="515"
BORDER="0"
CELLSPACING="0"
CELLPADDING="0"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="172"
><A
CLASS="SECT1"
HREF="ch01_22.htm"
TITLE="1.22 How UNIX Keeps Track of Files: Inodes "
><IMG
SRC="gifs/txtpreva.gif"
SRC="gifs/txtpreva.gif"
ALT="Previous: 1.22 How UNIX Keeps Track of Files: Inodes "
BORDER="0"></A
></TD
><TD
ALIGN="CENTER"
VALIGN="TOP"
WIDTH="171"
><A
CLASS="book"
HREF="index.htm"
TITLE="UNIX Power Tools"
><IMG
SRC="gifs/txthome.gif"
SRC="gifs/txthome.gif"
ALT="UNIX Power Tools"
BORDER="0"></A
></TD
><TD
ALIGN="RIGHT"
VALIGN="TOP"
WIDTH="172"
><A
CLASS="SECT1"
HREF="ch01_24.htm"
TITLE="1.24 The Superuser (Root) "
><IMG
SRC="gifs/txtnexta.gif"
SRC="gifs/txtnexta.gif"
ALT="Next: 1.24 The Superuser (Root) "
BORDER="0"></A
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="172"
>1.22 How UNIX Keeps Track of Files: Inodes </TD
><TD
ALIGN="CENTER"
VALIGN="TOP"
WIDTH="171"
><A
CLASS="index"
HREF="index/idx_0.htm"
TITLE="Book Index"
><IMG
SRC="gifs/index.gif"
SRC="gifs/index.gif"
ALT="Book Index"
BORDER="0"></A
></TD
><TD
ALIGN="RIGHT"
VALIGN="TOP"
WIDTH="172"
>1.24 The Superuser (Root) </TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="515"
TITLE="footer"><IMG
SRC="gifs/smnavbar.gif"
SRC="gifs/smnavbar.gif"
USEMAP="#map"
BORDER="0"
ALT="The UNIX CD Bookshelf Navigation"><MAP
NAME="map"
><AREA
SHAPE="RECT"
COORDS="0,0,73,21"
HREF="../index.htm"
ALT="The UNIX CD Bookshelf"><AREA
SHAPE="RECT"
COORDS="74,0,163,21"
HREF="index.htm"
ALT="UNIX Power Tools"><AREA
SHAPE="RECT"
COORDS="164,0,257,21"
HREF="../unixnut/index.htm"
ALT="UNIX in a Nutshell"><AREA
SHAPE="RECT"
COORDS="258,0,321,21"
HREF="../vi/index.htm"
ALT="Learning the vi Editor"><AREA
SHAPE="RECT"
COORDS="322,0,378,21"
HREF="../sedawk/index.htm"
ALT="sed &amp; awk"><AREA
SHAPE="RECT"
COORDS="379,0,438,21"
HREF="../ksh/index.htm"
ALT="Learning the Korn Shell"><AREA
SHAPE="RECT"
COORDS="439,0,514,21"
HREF="../lrnunix/index.htm"
ALT="Learning the UNIX Operating System"></MAP
></DIV
></BODY
></HTML
>