Files and access

To prevent all users from being able to access all files on the system, UNIX records information about who creates files and also who is allowed to access them later.

Each user has a unique username or loginnarne together with a unique user id or uid. The user id is a number, whereas the login name is a text string - otherwise the two express the same information. A file belongs to user A if it is owned by user A. User A then decides whether or not other users can read, write or execute the file by setting the protection bits or the permission of the file using the command chmod.

In addition to user identities, there are groups of users. The idea of a group is that several named users might want to be able to read and work on a file, without other users being able to access it. Every user is a member of at least one group, called the login group and each group has both a textual name and a number (group id). The uid and gid of each user is recorded in the file /etc/passwd (See chapter 6). Membership of other groups is recorded in the file /etc/group or on some systems /etc/logingroup.

Protection bits

The following output is from the command ls -lag executed On a SunOS type machine.

lrwxrwxrwx	1 root	wheel	7 Jun	1	1993 bin -> usr/bin
-r--r--r--	1 root	bin	103512 Jun	1	1993 boot
drwxr-xr-x	2 bin	staff	11264 May	11	17:00 dev
drwxr-xr-x	10 bin	staff	2560 Jul	8	02:06 etc
drwxr-xr-x	8 root	wheel	512 Jun	1	1993 export

The first column is a textual representation of the protection bits for each file. Column two is the number of hard links to the file (See exercises below). The third and fourth columns are the user name and group name and the remainder show the file size in bytes and the creation date. Notice that the directories /bin and /sys am symbolic links to other directories.

There are sixteen protection bits for a UNIX file, but only twelve of them can he changed by users. These twelve are split into four groups of three. Each three-bit number corresponds to one octal number.

The leading four invisible bits gives information about the type of file: is the file a plain file, a directory or a link. In the output from ls this is represented by a single character: -, d or 1.

The next three bits set the so-called s-bits and t-bit which are explained below.

The remaining three groups of three bits set flags which indicate whether a file can he read `’r’, written to ‘w’ or executed 'x' by (i) the user who created them. (ii) the other users who are in the group the file is marked with, and (iii) any user at all.

For example, the permission

                                                   Type Owner Group Anyone
                                                               d rwx r-x ---

tells us that the file is a directory, which can he read and written to by the owner, can be read by others in its group, but not by anyone else.

Here are some examples of the relationship between binary, octal and the textual repre­sentation of file modes.

Binary	Oct al	Text
001	1	x
010	2	w
100	4	r
110	6	TW-
101	5	r-x
-------	644	rw-r--r--

Unix chmod

The chmod command changes the permission or mode of a file. Only the owner of the file or the superuser can change the permission. Here are some examples of its use. Try them.

• make read/write-able for everyone chmod a+w myfile

• add the 'execute' flag for directory chmod u+x mydir/
• open all files for everyone chmod 755 *
• set the s-bit on my-dir's group chmod g+s mydir/
• descend recursively into directory opening all files chmod -R a+r dir

linux umask

When a new file gets created, the operating system must decide what default protection bits to set on that file. The variable umask decides this. umask is normally set by each user in his or her . cshrc file (see next chapter). For example

                                                 umask 077   # safe

                                                 umask 022    # liberal

According the UNIX documentation, the value of umask is 'XOR'ed (exclusive 'OR with a value of 666 & umask for plain files or 777 & umask for directories in order to find out the standard protection. Actually this is not quite true: `umask' only removes bits, it never sets bits which were not already set in 666. For instance

                                                umask                                Permission

                                                077                                      600 (plain)

                                                077                                     700 (dir)

                                                022                                     644 (plain)

                                                022                                     755 (dir)

The correct rule for computing permissions is not XOR but 'NOT AND'.

chown and chgrp

These two commands change the ownership and the group ownership of a file. Only the superuser can change the ownership of a file on most systems. This is to prevent users from being able to defeat quota mechanisms. (On some systems, which do not implement quotas, ordinary users can give a file away to another user but not get it back again.) The same applies to group ownership.

Linux sticky bit(s-bit) and t-bit

The s and t bits have special uses. They are described as follows.

                                    Octal             Text                 Name

                                     4000             chmod u+s      Setuid bit

                                     2000             chmod g+s      Setgid bit

                                     1000                chmod +t     Sticky bit

The effects of these bits differ for plain files and directories and differ between different versions of UNIX. You should check the manual page man sticky to find out about your system! The following is common behaviour.

For executable files, the setgid bit tells UNIX that regardless of who runs the program it should be executed with the permissions and rights of owner of the file. This is often used to allow normal users limited access to root privileges. A setgid-root program is executed as root for any user. The setgid bit sets the group execution rights of the program in a similar way.

In BSD UNIX, if the setgid bit is set on a directory then any new files created in that directory assume the group ownership of the parent directory and not the logingroup of the user who created the file. This is standard policy under system 5.

A directory for which the sticky bit is set restrict the deletion of files within it. A file or directory inside a directory with the t-bit set can only be deleted or renamed by its owner or the superuser. This is useful for directories like the mail spool area and /tmp which must be writable to everyone, but should not allow a user to delete another user's files.

Introduction to Bourne Again Shell(bash basic)

The Bourne Again shell (Bash) is the command interpreter which you use to run pro-grams and utilities. It contains a simple programming language for writing tailor-made commands, and allows you to join together UNIX commands with pipes. It is a config­urable environment, and once you know it well, it is the most efficient way of working with UNIX.

The Bourne Again shell was written by the Free Software Foundation as a part of the GNU project and Bash is the default shell in most GNU/Linux distributions. Because of its command line editing features, it is much more efficient for interactive use than Bourne shell, the original UNIX shell. Most of the system scripts in UNIX are written in the Bourne shell. Although Bash includes many extensions and features not found in the Bourne shell, it maintains compatibility with it so that you can run Bourne shell scripts under Bash. On many GNU/Linux systems Bourne shell (`/bin/sh') is symbolically linked to Bash (`/bin/bash') so that the scripts that require the presence of the Bourne shell still run. If you want to write a platform independent shell script able to run on as many UNIX variants as possible, you should stick to Bourne shell syntax and avoid the Bash extensions.

                                        `/.bashrc' and ‘~/ bash_profile' files

When you log on to a GNU/Linux system and your login shell is defined in 'etc/passwd' to he Bash, it first executes commands in the 'etc/profile' file. It then searches for the '/ bash_profile', .bash_login' or 'profile' file, in this order, and executes commands in the first of these that is found and is readable. When a login exits, it executes commands in the                                                                        '~/.bash_logout' file.

When you start an non-login interactive Bash shell, it only executes commands in the `"/ .bashrc file, if it exists and is readable. However, this shell inherits any environment (exported) variables from the parent shell, so environment variables set in '/etc/profile and '~/.bash_profile' are passed onto the non-login shells and later to its subshells.

Bash variable and export

Shell variables are defined using the syntax

                                    VARIABLE="username is"
                                     myname="mark"

It is important that there be no space between the variable and the equals sign. These variables are then referred to using the dollar ‘$’  symbol.

                                     $ echo "My  $VARIABLE  $myname"
                                      My username is mark

When assigning values to variables the dollar symbol is never used. By default these variables are local - that is they will not be passed on to programs and sub-shells running under the current shell. To make them global (so that child processes will inherit them) we use the command                                       

                                  export VARIABLE

This adds the variable to the process environment. Under Bash (but not under the old Bourne shell) it is also possible to declare a variable to be global on a single line by                                       

                                   export GLOBALVAR="global"

The command

                   set -a

Changes the default so that all variables, after the command are created global.

Arrays or lists are often simulated in Bourne shell by sandwiching the 'colon : ' symbol between items

PATH=/bin : /usr/bin : /etc : /local/bin : 

LD_LIBABAY_PATH=/usr/lib:/usr/openwin/lib:/local/lib

                       $ animal=worm
                       $ echo book$animal
                       bookworm
                       $ thing=book
                       $ echo $thingworm
                       (nothing..)
                       $ echo ${thing}worm bookworm
                       echo ${var-"No value set"}
                       echo ${var="Octopus"}
                       echo ${var+"Forced value"}
                       echo ${var?"No such variable"}

The first of these prints out the contents of ‘$var’ , if it is defined. If it is not defined the variable is substituted for the string "No value set". The value of `var’ is not changed by this operation. It is only for convenience.

The second command has the same effect as the first, but here the value of 'var' is actually changed to "Octopus" if '$var' is not set.

The third version is slightly peculiar. If '$var' is already set, its value will be forced to be "Forced value", otherwise it is left undefined.

Finally the last instance issues an error message "No such variable" if '$var' is not defined.

In Bash 2.x it is possible to extract parts of the string a variable is set to using the construction ${variable : off set : length} | as shown in the next example.                              

                                   Var="abcdefg"
                                   Middle={var : 2 : 3} echo $middle
                                   Cde

Bash array

The original Bourne shell does not have arrays. Bash version 2.x does have arrays. however. An array can be assigned from a string of words separated by whitespaces or the individual elements of the array can be set individually.                   

                         colours- (red white green)
                         colours [3] ="yellow"

An element of the array must be referred to using curly braces.

                                echo ${colours [1] }
                                white

Note that the first element of the array has index 0. The set of all elements is referred to by ${colours[*]}             

                                   echo ${colours[*]}
                                   red white green yellow
                                   echo ${#colours[*]}
                                   4

Bash array Stdin, stdout, stderr and redirection to and from file:

When the shell starts up, it inherits three files: `stdin` `stdout`, and `stderr`. Stan­dard input normally comes from the keyboard. Standard output and standard error nor­mally go to the screen. There are times you want to read input from a file or send output of errors to a file. This can be accomplished by using I/O redirection.

In Bash and the Bourne shell, the standard input/output files are referred to by numbers rather than by names.

                                                         stdin                 File number 0

                                                        stdout                File number 1

                                                        stderr                File number 2

The default routes for these files can be changed by redirection. The output of the command echo is by default sent to the screen that is the stdout with file number 1 is sent to the screen. Using redirection operators it is possible to redirect the standard out of echo to where we want it. We can send output to a file with the following command.                                     

                           echo "should be sent to a file" > file.txt

This creates a new file 'file.txt' containing the string 'should be sent to a file'. The redirection operator could have been given as 1>, but it is understood that standard out is meant when skipping the number of the file handle. The single '>' always creates a new file, while '>>' appends to the end of a file.

If you had mistyped the command echo the result would have been:

           echo "should be sent to a file" > file.txt bash: echo: command not found

The standard error with file handle 2 is by default sent to the screen, independent of where standard out (1) is sent. If you like you can redirect stdout to another or the same file.

          echo "should be sent to a file" > file.txt 2> error.txt cat error.txt
          bash: echo: command not found

There are several ways to send stderr to the same file as stdin is redirected to. The following three commands are equivalent.

echo "should be sent to a file" >& file.txt
echo "should be sent to a file" > file.txt 2> file.txt echo "should be sent to a file" > file.txt 2>&1

The string 2>&1 means that stderr(2) should be sent to the same file as stdout(1). This is the only why to do this under the Bourne shell and this construction is therefore often seen in system shell scripts.

                                           Redirection operator       What it does

                                           <                                     Redirects input

                                           >                                    Redirects output

                                           >>                                   Appends output

                                           2>                                    Redirects error

                                           >&                                   Redirects output and error (Bash only) 2>&1          

                                           2>&1                              Redirects error where output (1) is going