ch22_02.htm

the unix power tools

></LI
><LI
CLASS="listitem"
><P
CLASS="para"
>The information is not personal, yet no one should be able to modify
the information. Most of my directories are set up this way, with the permissions
of 755.</P
></LI
><LI
CLASS="listitem"
><P
CLASS="para"
>The files are managed by a team of people. This means group-write permission,
or directories with the mode 775.</P
></LI
><LI
CLASS="listitem"
><P
CLASS="para"
>In the previous case, for confidential projects, you may want to deny
access to people outside the group.
In this case, make directories with mode 770.</P
></LI
></OL
><P
CLASS="para"
>You could just create a directory with the proper permissions,
and put the files inside the directory, 
hoping the permissions of the directory will 
&quot;protect&quot;
the files in the directory.
This is not adequate. Suppose you had a directory with permissions
755 and a file with permissions 666 inside the directory.
Anyone could change the contents of this file because 
the world has search access on the directory and
write access to the file.</P
><P
CLASS="para"
>What is needed is a mechanism to prevent any new file from having world-write access.
This mechanism exists with the<A
CLASS="indexterm"
NAME="AUTOID-23848"
></A
><A
CLASS="indexterm"
NAME="AUTOID-23850"
></A
>
<SPAN
CLASS="link"
><EM
CLASS="emphasis"
>umask</EM
> command (<A
CLASS="linkend"
HREF="ch22_04.htm"
TITLE="Setting an Exact umask "
>22.4</A
>)</SPAN
>.
If you consider that a new directory would get permissions of 777, 
and that new files would get permissions of 666, the
<EM
CLASS="emphasis"
>umask</EM
>
command specifies permissions to 
&quot;take away&quot;
from all new files.
To 
&quot;subtract&quot;
world-write permission from a file, 666 must have 002 
&quot;subtracted&quot;
from the default value to get 664.
To subtract group and world write, 666 must have 022 removed to leave
644 as the permissions of the file.
These two values of
<EM
CLASS="emphasis"
>umask</EM
>
are so common that it is useful to have some
<SPAN
CLASS="link"
>aliases (<A
CLASS="linkend"
HREF="ch10_02.htm"
TITLE="Aliases for Common Commands "
>10.2</A
>)</SPAN
>
defined:</P
><P
CLASS="para"
><BLOCKQUOTE
CLASS="screen"
><PRE
CLASS="screen"
>&#13;alias open umask 002
alias shut umask 022</PRE
></BLOCKQUOTE
></P
><P
CLASS="para"
>With these two values of 
<EM
CLASS="emphasis"
>umask</EM
>,
new directories will have permissions of 775 or 755.
Most people have a
<EM
CLASS="emphasis"
>umask</EM
>
value of one of these two values.</P
><P
CLASS="para"
>In a friendly work group, people tend to use the 
<EM
CLASS="emphasis"
>umask</EM
>
of 002, which allows others in your group to make changes to your files.
Someone who uses the mask of 022 will cause grief to others working on a project.
Trying to compile a program is frustrating when someone else owns files that you 
must delete but can't. You can rename files if this is the case 
or ask the system administrator for help.</P
><P
CLASS="para"
>Members of a team who normally use a default umask of 022 should find a 
means to change the mask value when working on the project.
(Or else risk flames from your fellow workers!)
Besides the
<EM
CLASS="emphasis"
>open</EM
>
alias above, some people have an alias that changes directories and
sets the mask to group-write permission:</P
><P
CLASS="para"
><BLOCKQUOTE
CLASS="screen"
><PRE
CLASS="screen"
>alias proj &quot;cd /usr/projects/proj;umask 002&quot;</PRE
></BLOCKQUOTE
></P
><P
CLASS="para"
>This isn't perfect, because people forget to use aliases.
You could have a special <EM
CLASS="emphasis"
>cd</EM
> alias and a private shell file in each
project directory that sets the <EM
CLASS="emphasis"
>umask</EM
> when you <EM
CLASS="emphasis"
>cd</EM
> there.
Other people could have similar files in the project directory
with different names.
Article
<A
CLASS="xref"
HREF="ch14_14.htm"
TITLE="Automatic Setup When You Enter/Exit a Directory "
>14.14</A
>
shows how.</P
><P
CLASS="para"
>Still another method is to run 
<SPAN
CLASS="link"
><EM
CLASS="emphasis"
>find</EM
> (<A
CLASS="linkend"
HREF="ch17_01.htm#UPT-ART-7410"
TITLE="The find Command Is Great; The Problem Is Finding How to Use It"
>17.1</A
>)</SPAN
>
three times a day
and search for files owned by you in the project directory that
have the wrong permission:</P
><P
CLASS="para"
><TABLE
CLASS="screen.co"
BORDER="1"
><TR
><TH
VALIGN="TOP"
><PRE
CLASS="calloutlist"
>
<A
CLASS="co"
HREF="ch06_03.htm"
TITLE="6.3 Predefined Environment Variables "
>$USER</A
> 
<A
CLASS="co"
HREF="ch09_21.htm"
TITLE="9.21 Handle Too-Long Command Lines with xargs "
>xargs</A
> <A
CLASS="co"
HREF="ch22_07.htm"
TITLE="22.7 Using chmod to Change File Permission "
>chmod</A
> </PRE
></TH
><TD
VALIGN="TOP"
><PRE
CLASS="screen"
>
% <CODE
CLASS="userinput"
><B
>find /usr/projects -user $USER ! -perm -020 -print | \</B
></CODE
>
<CODE
CLASS="userinput"
><B
>xargs chmod g+w</B
></CODE
></PRE
></TD
></TR
></TABLE
></P
><P
CLASS="para"
>You can use the command
<SPAN
CLASS="link"
><EM
CLASS="emphasis"
>crontab -e</EM
> (<A
CLASS="linkend"
HREF="ch40_15.htm"
TITLE="crontab Script Makes crontab Editing Easier/Safer "
>40.15</A
>, <A
CLASS="linkend"
HREF="ch40_12.htm"
TITLE="Periodic Program Execution: The cron Facility "
>40.12</A
>)</SPAN
>
to define when to run this command.<A
CLASS="indexterm"
NAME="AUTOID-23889"
></A
><A
CLASS="indexterm"
NAME="AUTOID-23890"
></A
>
[If your system doesn't have personal <EM
CLASS="emphasis"
>crontab</EM
>s, use a
<SPAN
CLASS="link"
>self-restarting <EM
CLASS="emphasis"
>at</EM
> job (<A
CLASS="linkend"
HREF="ch40_08.htm"
TITLE="Automatically Restarting at Jobs "
>40.8</A
>)</SPAN
>.
<EM
CLASS="emphasis"
>-JP</EM
>&nbsp;]</P
></DIV
><DIV
CLASS="sect2"
><H3
CLASS="sect2"
><A
CLASS="title"
NAME="UPT-ART-417-SECT-1.2"
>22.2.2 Which Group is Which? </A
></H3
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-23898"
></A
>Since group-write permission is so important in a team project, 
you might be wondering how the group of a new file is determined?
The answer depends on several factors.
Before I cover these, you should note that Berkeley and AT&amp;T-based systems 
would use different mechanisms to determine the default group.</P
><P
CLASS="para"
>Originally UNIX required you to specify a new group
with the
<EM
CLASS="emphasis"
>newgrp</EM
>
command.
If there was a password for this group in the
<EM
CLASS="emphasis"
>/etc/group</EM
>
file, and you were not listed as one of the members of the group,
you had to type the password to change your group.</P
><P
CLASS="para"
>Berkeley-based versions of UNIX would use the current directory to determine
the group of the new file. That is, if the current directory has 
<EM
CLASS="emphasis"
>cad</EM
>
as the group of the directory,
any file created in that directory would be in the same group.
To change the default group, just change to a different directory.</P
><P
CLASS="para"
>Both mechanisms had their good points and bad points.
The Berkeley-based mechanism
made it convenient to change groups automatically.
However, there is a fixed limit of groups one could belong to.
SunOS 4 has a limit of 16 groups. 
Earlier versions had a limit of eight groups.</P
><P
CLASS="para"
>SunOS and System V Release 4 support both mechanisms.
The entire disk can be mounted with either
the AT&amp;T or the Berkeley mechanism. If it is necessary to control this
on a directory-by-directory basis, a
<SPAN
CLASS="link"
>special bit (<A
CLASS="linkend"
HREF="ch22_05.htm"
TITLE="Group Permissions in a Directory with the setgid Bit "
>22.5</A
>)</SPAN
>
in the file permissions is used.
If a disk partition is mounted without the Berkeley group mechanism, 
then a directory with this special bit will make new files have the same group
as the directory.
Without the special bit, the group of all new files depends on the
current group of the user.</P
></DIV
><DIV
CLASS="sect1info"
><P
CLASS="SECT1INFO"
>- <SPAN
CLASS="authorinitials"
>BB</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="ch22_01.htm"
TITLE="22.1 Introduction to File Ownership and Security "
><IMG
SRC="gifs/txtpreva.gif"
SRC="gifs/txtpreva.gif"
ALT="Previous: 22.1 Introduction to File Ownership and Security "
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="ch22_03.htm"
TITLE="22.3 Who Will Own a New File? "
><IMG
SRC="gifs/txtnexta.gif"
SRC="gifs/txtnexta.gif"
ALT="Next: 22.3 Who Will Own a New File? "
BORDER="0"></A
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="172"
>22.1 Introduction to File Ownership and Security </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"
>22.3 Who Will Own a New File? </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
>