LPIC-1 EXAM PREP (COURSE 1)

(1)

LPI101 | Student Edition |

LPI101S-R54S11U804-D00

Course Code

Course Title

LPI101

LPIC-1 Exam Prep

(course 1)

(2)

LPI101

LPIC-1 EXAM

PREP (COURSE 1)

RHEL5.4 SLES11 U804

No part of this publication may be stored in a retrieval system, transmitted or reproduced in any way, including, but not limited to, photocopy, photograph, magnetic, electronic or other record, without the prior written permission of Guru Labs.

This curriculum contains proprietary information which is for the exclusive use of customers of Guru Labs L.C., and is not to be shared with personnel other than those in attendance at this course. This instructional program, including all material provided herein, is supplied without any guarantees from Guru Labs L.C. Guru Labs L.C. assumes no liability for damages or legal action arising from the use or misuse of contents or details contained herein.

Photocopying any part of this manual without prior written consent of Guru Labs L.C. is a violation of federal law. This manual should not appear to be a photocopy. If you believe that Guru Labs

(3)

Chapter

1

MANAGE FILE

PERMISSIONS AND

OWNERSHIP

Content

LPI Objectives Covered . . . 2

Filesystem Hierarchy Standard . . . 3

Navigating the Filesystem . . . 5

Displaying Directory Contents . . . 6

Determining Disk Usage . . . 7

File Ownership . . . 8

Default Group Ownership . . . 9

File and Directory Permissions . . . 10

File Creation Permissions . . . 11

Changing File Permissions . . . 13

SUID and SGID on files . . . 14

SGID and Sticky Bit on Directories . . . 15

User Private Group Scheme . . . 16

Lab Tasks 17 1. Files and Directories . . . 18

2. Disk and Filesystem Usage . . . 20

(8)

LPI Objectives Covered

104.5 Manage File Permissions and Ownership 103.3 Perform Basic File Management (partial)

104.5 Manage File Permissions and Ownership (Weight 3)

Candidates should be able to control file access through the proper use of permissions and ownerships.

Key Knowledge Areas:

y Manage access permissions on regular and special files as well as directories.

y Use access modes such as suid, sgid and the sticky bit to maintain security.

y Know how to change the file creation mask.

y Use the group field to grant file access to group members. The following is a partial list of the used files, terms and utilities:

(9)

Filesystem Hierarchy Standard

Filesystem standard – FHS

• Guiding principles for each area of filesystem • Predictable location of files and directories

Provides uniformity across multiple Linux distributions

The Linux Standards Base

• Aims to allow Linux binaries to run unmodified on multiple Linux distributions

• Specifies system and library interfaces and environment • Incorporates the FHS

Filesystem Hierarchy Standard

Most Linux distributions follow the guidelines defined in the

Filesystem Hierarchy Standard or FHS. This standard gives specific guidelines for what types of files should be contained in the various directories on the system. The process of developing a standard filesystem hierarchy began in August 1993 with an effort to

restructure the file and directory structure of Linux. The FSSTND, a filesystem hierarchy standard specific to the Linux operating system, was released on February 14, 1994. Subsequent revisions were released on October 9, 1994 and March 28, 1995

In early 1995, the goal of developing a more comprehensive version of the FSSTND to address not only Linux, but also other UNIX-like systems, was adopted with the help of members of the BSD

development community. As a result, a concerted effort was made to focus on issues that were general to UNIX-like systems. In

recognition of this widening of scope, the name of the standard was changed to Filesystem Hierarchy Standard, or FHS for short.

The official FHS standard can be found at:

http://www.pathname.com/fhs/

The Linux Standards Base

The FHS has been incorporated into the Linux Standards Base (LSB) which has larger coverage then just the filesystem directory structure and includes binaries and libraries. For detail see:

(10)

FHS Defined Directories

The following list of definitions shows the directories whose purpose is defined in the FHS. Note that this is not a list of every single directory found on a common Linux installation.

The Root Filesystem

The root (

/

) filesystem contains configuration files, device nodes, and binaries essential to system bootup. The configuration files contain host specific data and therefore, unless special measures are taken, a root filesystem can not be shared among multiple hosts. The root filesystem should contain commands and utilities for performing troubleshooting and recovery procedures even if the rest of the filesystems are not available. Because the root filesystem is critical to the operation of the system, often it is kept as small as possible so that it is less likely that a physical disk error, such as a bad sector, can cause damage to it.

/

⇒ The root directory

/bin/

⇒ Essential command binaries

/boot/

⇒ Static files of the boot loader, kernel, and initial RAM disk

/dev/

⇒ Device files

/etc/

⇒ Host-specific system configuration

/home/

⇒ User home directories

/lib/

⇒ Essential shared libraries and kernel modules

/media/

⇒ Mount point for removable media (LSB addition)

/mnt/

⇒ Mount point for mounting a filesystem temporarily

/opt/

⇒ Add-on application software packages

/root/

⇒ Home directory for the root user

/sbin/

⇒ Essential system binaries

/srv/

⇒ Data files for system services (LSB addition)

/tmp/

⇒ Temporary files

/usr/

⇒ Second hierarchy. Non-essential read-only data (see

/usr/

breakout for details)

/var/

⇒ Variable data files. Includes spool directories and files, administrative and logging data, and transient and temporary files

will be consumed under the

/usr/

hierarchy. Because the files and

directories in

/usr/

can be recreated by reinstalling applications, it is not usually backed up.

/usr/bin/

⇒ Most user commands

/usr/include/

⇒ Header files included by C programs

/usr/lib/

⇒ Libraries

/usr/local/

⇒ Local hierarchy (empty after main installation)

/usr/sbin/

⇒ Non-vital system binaries

/usr/share/

⇒ Architecture-independent data The /var/ Hierarchy

This directory contains data that changes on a regular basis (variable data). When applications run, any temporary or permanent files that are created are normally stored under

/var/

. Additionally, operating system and application log files are stored here. Best practice is to have

/var/

be a separate filesystem so that an errant application can't cause the root filesystem to run out of space.

/var/cache/

⇒ Application cache data

/var/lib/

⇒ Variable state information

/var/local/

⇒ Variable data for

/usr/local

/var/lock/

⇒ Lock files

/var/log/

⇒ Log files and directories

/var/opt/

⇒ Variable data for

/opt

/var/run/

⇒ Data relevant to running processes

/var/spool/

⇒ Application spool data

/var/tmp/

⇒ Temporary files preserved between system reboots Linux kernel Virtual Hierarchies

Following the long standing UNIX practice of representing everything as a file, the Linux kernel has special virtual filesystems that provide information and tunables parameters. Since the filesystems are virtual, they don't actually use any space on disk.

(11)

Navigating the Filesystem

Changing and displaying directories

• cd, pwd

Absolute vs. relative addressing Special cases • cd(without parameters) • cd žusername • cd ž • cd -• .and..

Navigating the Filesystem

The

cd

command changes the current directory. Typing

cd /usr

at

the command line will change you to the

/usr/

directory. To find out

the current directory, use the

pwd

command. When typed at the

command line, the output will be an absolute path such as

/home/ftp/pub

. You can tell this is an absolute path because it

begins with a

/

. An absolute path always begins with a

/

and

describes a location from the top, or root, of the filesystem. Another type of path is a relative path. A relative path never begins with a

/

, and instead describes a location from, or relative to, the current directory. If your current directory is

/usr/

and you type

cd

local/bin

your current directory would be changed to

/usr/local/bin/

.

When typed alone without any parameters, the

cd

command takes

you to your home directory. Note that if you are logged in as root, you will be taken to

/root/

which is the root user's home directory. The

.

character represents the current directory. Typing

cd .

at the command line has no effect because you will stay in the same directory. Typing

cd ..

will take you to the parent of the current directory.

For example, if you are in

/home/foo/

and you type

cd ..

you will end up in the

/home/

directory. The .. may be used in a relative path and may be used multiple times in that path.

If the current location is

/home/meta/cal/jan/

the following are all

acceptable examples:

cd ../foo

will take you to

/home/meta/cal/foo/

cd ../../foo

will take you to

/home/meta/foo/

cd ../../../foo

will take you to

/home/foo/

cd ../..

will take you to

/home/meta/

cd žusername

will take you to

username

's home directory

(12)

Displaying Directory Contents

lsList directory contents

• -ashow all files (including.hiddenfiles) • -llong listings

• -dshow directories not contents • -hhuman readable file sizes • -Rrecursively list sub-directories • -Ssort file list by size

Displaying Directory Contents

The

ls

command is used to list the contents of a directory and is

similar to the

dir

command in MS-DOS / Windows. Here are a few

examples of the

ls

command starting with the default output, and

then showing the effect of various options:

$ ls

bin etc lib pub testfile

Show all files (including "hidden" dot-files):

$ ls -a

. .. .hiddenfile bin etc pub testfile

Show long listing:

$ ls -l

total 16

d--x--x--x 2 root root 4096 Jun 1 22:10 bin

d--x--x--x 2 root root 4096 Jun 1 22:10 etc

drwxr-sr-x 2 root ftp 4096 Aug 28 01:13 pub

-rw-rw-r-- 1 root root 0 Aug 31 21:48 testfile

-rw-rw-r-- 1 root root 0 Aug 31 21:49 .hiddenfile

d--x--x--x 2 root root 4.0k Jun 1 22:10 bin

d--x--x--x 2 root root 4.0k Jun 1 22:10 etc

drwxr-sr-x 2 root ftp 4.0k Aug 28 01:13 pub

-rw-rw-r-- 1 root root 0 Aug 31 21:48 testfile

Sorting File Listings

Output from the

ls

command can be sorted a wide variety of ways

as shown in the following examples: Long listing sorted by file size:

$ ls -lS

. . . output omitted . . .

Long listing sorted file's change timestamp:

$ ls -lc

. . . output omitted . . .

Long listing sorted by file's access (instead of the default modify) timestamp:

(13)

Determining Disk Usage

duSummarize disk usage for directories

• -hhuman readable sizes

• -ssummarize, display total only for each argument • -Sdo not include size of sub-directories

dfReport filesystem disk space usage

• -hhuman readable output

• -ilist inode information instead of block usage • -Tinclude filesystem type

Determining Disk Usage by File

The

du

command shows the estimated disk space used by files and

directories. If you execute

du

without any options it will output the sizes of all files starting in your current directory and all

sub-directories of your current directory.

Find out how much disk space the

/home

directory is using with the

summarize (

-s

) and human readable (

-h

) options:

$ du -hs /home

1.7G /home

Adding the no sub-directories (

-S

) option shows only the disk space used by files in the

/home

directory without counting files in

sub-directories of

/home

:

$ du -hsS /home

13M /home

Determining Disk Usage by Filesystem

The

df

command shows how much space each filesystem is using

on the disk and where it is mounted. Using the

-i

options shows

inode usage instead of free space. Each file on the system uses an inode. Running out of free space or inodes will cause serious

problems and you should add more disk space to the system if either is in danger of running out!

With the type (

-T

) and the human readable (

-h

) option

df

shows the filesystem type, and counts sizes in megabytes and gigabytes:

$ df -hT

Filesystem Type Size Used Avail Use% Mounted on

/dev/hda9 ext2 252M 136M 102M 57% /

/dev/hda1 ext2 19M 5.5M 12M 31% /boot

/dev/hda6 ext2 508M 156M 326M 32% /tmp

/dev/hda5 ext2 2.0G 1.6G 238M 88% /usr

/dev/hda7 ext2 252M 115M 124M 48% /var

/dev/hdc1 ext2 2.3G 1.7G 563M 75% /home

(14)

File Ownership

Each file is owned by a specific UID and GID

chown – Change the user (UID) ownership

• Onlyrootcan change ownership to another user • Can also be used to change group at the same time

chgrp – Modify just the group (GID) ownership

File Ownership

Every file is owned by a specific user (or UID) and a specific group (or

GID). The

chown

command can be used to change just the user, or

the user and group of a file. Here is an example of changing the

owner of file

game.mov

to nobody and its group to users. Note that

the use of the

ls -l

command is just to show the change, and is not

a necessary step in changing the file's ownership:

# ls -l game.mov

-rw-rw-r-- 1 jmh jmh 6551550 Apr 17 12:03 game.mov

# chown nobody.users game.mov

# ls -l game.mov

-rw-rw-r-- 1 nobody users 6551550 Apr 17 12:03 game.mov

The basic format for the

chown

command is as follows:

chown user.group filename

A colon (

:

) can be used in place of the period (

.

) separator character.

Also, either the

user

or

group

name can be omitted. If the username

is omitted (but the separator character is present), then the

chown

command behaves like the

chgrp

command, and only the group

An alternate command to change only the group of a file is the

chgrp

command. For example:

$ chgrp group filename

The

chgrp

command is commonly used by normal users to change

the group ownership of their files. The

chown

command is normally

(15)

Default Group Ownership

Newly created files will usually be given GID ownership based on the current active group of the person who creates the file

newgrp newgroup- log in to a new group

• newly created files will be owned by the new group • users can only change to their own groups

• rootuser can change to any group • exitto switch back

Default Group Ownership

Each user can be a member of many groups (listed in the

/etc/group

file under several groups). Only one group will be a user's primary group (listed in the user's entry in

/etc/password

). When a user creates a file, by default the file will be owned by the user's primary group. If they want the file to be owned by one of their other groups,

they must use the

chgrp

command to modify the group membership.

A more convenient way to accomplish this is to temporarily log-in to another group, making that group your substitute primary group. This way, any new files that you create will automatically be owned by the desired group, and you will not need to change the group

membership manually. Examine the example below and note the use

of the

newgrp

command.

$ id -gn

guru

$ touch file1

$ ls -l file1

-rw-rw-r-- 1 guru guru 0 Mar 3 01:12 file1

$ newgrp projectx

$ id -gn

projectx

$ touch file2

$ ls -l file2

-rw-rw-r-- 1 guru projectx 0 Mar 3 01:12 file2

$ exit

(16)

File and Directory Permissions

ls -lList file permissions

• first character represents type of file (d,-,l,b,c,s,p)

Then permission sets for:

• user -UID that owns the file (sometimes called owner) • group -GID that owns the file

• everyone else (sometimes called other)

Permissions can be represented in two ways

• symbolic representation (e.g.rwxr-xr-x) • numeric representation (e.g.0755)

File and Directory Permissions

Below is sample output from

ls -l

; you can see from the first character of each line that

foo

and

bar

are directories (indicated by the

d

) and that

-

).

$ ls -l

-rw-rw-r-- 1 guru projectx 0 Mar 3 01:13 file

drwxrwxr-x 3 djk users 4096 Aug 31 20:35 bar

drwxrwxr-x 2 jmh users 4096 Aug 31 20:35 foo

-rw-rw-r-- 1 kbk kbk 0 Sep 1 09:48 data_file

The next nine characters show the file's permissions for user, group, and others (or everyone else) as shown below, with parentheses added for clarity:

-(rw-)(rw-)(r--) 1 kbk kbk 0 Sep 1 09:48 data_file

Now the owner has read and write permissions (

rw-

), the group has

read and write permissions (

rw-

), and everyone else has only read permissions (

r--

). This is called symbolic representation because letters such as

r

,

w

, and

x

, are used to indicate permissions.

Permissions: Numerical Representation

Permissions can also be represented in a more compact numerical form where: r = 4; w = 2; x = 1

To find the numerical representation, add the values of the set permission within each triplet to yield a final 3 digit mode. For

example using the previously shown

data_file

file, adding the

numbers in each section results in permissions of

664

as shown

here:

-(rw-)(rw-)(r--)

-(42-)(42-)(4--)

6 6 4

(17)

File Creation Permissions

Default permissions for newly created filesystem objects

• files:666

• directories:777

umask

• defines what permissions to withhold from the default permissions

• used to display or change your umask

• usually set in the user or system shell dot files • used to provide the user private group (UPG) scheme

Controlling Initial File and Directory Permissions

When new files and directories are created in Linux, default permissions are initially set. These permissions are calculated by taking the default permissions of the files/directories created and subtracting the umask value from it. The umask is a four digit octal number that represents the value of permissions that will be masked out. In other words, permissions specified in the umask represent the permissions that will be automatically withheld when you create a new file.

Files and directories have different default permissions when they are created. The default permissions applied to files is

0666

. For

directories, the default permissions are

0777

. The following example illustrates the process of how initial file permissions are calculated:

666 Default File permission.

-002 Umask value

664 Initial file permission (rw-rw-r--)

Viewing and Setting the umask Value

The

umask

command is the utility that is provided to view or change the current umask. The umask comes preset in configuration files and to view the current umask issue the command without any options:

$ umask

0002

The umask may be changed at any time simply by typing

umask

followed by the new desired value. Notice that the leading digit is not required if it is zero, (and is zero by default):

$ umask 022

$ umask

0022

[RHEL5.4] The following applies to RHEL5.4 only:

As a user in RHEL5.4 your default umask is set to

002

. This means

that all files you create will have permissions of

664

, read/write for user and group, and read for others. Since the default permissions of a file are

666

, a umask of

002

results in files with permissions of

664

. The

root

account has a default umask of

022

subsequently, all files

created by the

root

user have default permissions of

644

(

rw-r--r--

), allowing only read access to anyone other than

root

.

You might have noticed that a default umask of

002

gives away write

permission to all group members. In the User Private Group (UPG) scheme, your default group is a private group just for you, with the same group name as your username. The result is that newly created files are only writable by that user.

[SLES11] The following applies to SLES11 only:

In SLES11, the default umask for all users is set to

022

(defined by

pam_umask(8)

). SUSE makes all users' default group the

users

group. When creating files, write access will only be granted to the user who created the file and not to anyone in the

users

group.

(18)

[U804] The following applies to U804 only:

All users in U804 have a default umask of

022

(defined in

/etc/profile

). Users are assigned a group name (the default primary group) matching their user name (and typically UID number).

It is recommended to change the umask default to

002

. This

preserves write access by only the file owner, while facilitating the administrative ease of allowing users to share files to other groups without requiring a change of permissions. It is important to avoid the

(19)

Changing File Permissions

chmod Modify file permissions

• -Rrecursively modify permissions

• supports both numeric and symbolic notation • special permissions

• set UID (SUID) • set GID (SGID) • sticky

Special permissions cause different behavior for files and directories

Changing File Permissions

The

chmod

command is used to alter the permissions of a file. It may be used to add or remove permissions symbolically. For example, to add execute permissions for the owner of a file you would run:

$ chmod u+x file_name

Or, to add read and write permissions for the group that owns the file, you would run:

$ chmod g+rw file_name

Instead of adding permissions, the symbolic syntax of

chmod

can also

be used to subtract or set to some absolute value as shown in these examples:

$ chmod o-w file_name

$ chmod u=rwx,g=rx,o= file_name

The

chmod

command can also explicitly set permissions using a numerical representation. For example, to set permissions on a file to

rwxrwxr--

, you would run:

$ chmod 774 file_name

In addition to the standard read, write, and execute permissions,

chmod

can also set special permissions. These are the setuid bit, the setgid bit, and the sticky bit. The following examples show setting each of these special permissions along with brief descriptions of the effect of those permissions (Note: the effect of these special

permissions are described more fully in the upcoming pages):

$ chmod u+s file_name

Adds the setuid bit so that, if executable, this file will execute with the permissions of its owner.

$ chmod g+s file_name

Adds the setgid bit so that, if executable, this file will execute with the permissions of its group. When this is set on a directory, all files created in the directory will have the same group as the directory.

$ chmod o+t directory_name

Adds the sticky bit so that users can only delete files from this directory that they created.

$ chmod -R g+rwX directory_name

Adds read, write, and execute permissions recursively to the directory specified, but does not add the x-bit for non-directories.

(20)

SUID and SGID on files

The SUID bit changes the security context of an executable

An executable is normally run with the security context of the user who invoked it

An executable with the SUID bit set runs with the security context of the user who owns it, regardless of the executing user

Special Permissions on Files: SUID

New Linux users often wonder why anyone would ever want to use the SUID bit. Having a program that will run with the power of

root

for any user sounds like a dangerous proposition. As it turns out, setting the SUID bit on certain programs is not only helpful, it is required.

Take, for example, the

passwd

command. Any user on the system

may use the

passwd

command to change their password. Users'

passwords are stored in the file

/etc/shadow

. A quick check of the permissions on this file will reveal that it is read / write only to the

root

user. In order to update the entry for their password, a user must have

root

level access to the file. This access is provided by

setting the SUID bit on the

passwd

program. The

passwd

program will

only allow a user to change their own password. This limitation is imposed based on the UID of the user running the program, but not on the user's security context.

Special Permissions on Files: SGID

When executable files with the SGID bit set are run, they will run with an effective group id (EGID) of the group that owns the executable

(perhaps changing permissions and ownership on certain files and directories) such that it no longer needs the SUID bit set. If this is possible, do it. If not, evaluate whether or not the program in question is needed.

SUID and SGID files can be discovered using the

find

command. The

following finds all files owned by

root

which have the SUID

permission bit set:

# find / -type f -user root -perm +4000

. . . output omitted . . .

The following finds all files which have the SGID permission bit set:

# find / -type f -perm +2000

. . . output omitted . . .

(21)

SGID and Sticky Bit on Directories

SGID

• Files or sub-directories created within that directory inherit the group ownership of the SGID directory

• Often used to facilitate collaboration among users who need to share files

Sticky bit

• Normally in a directory that is world writable, users can delete each other's files. Setting the sticky bit overrides this behavior

Special Permissions on Directories: SGID

If the SGID permission is set on a directory, then files or sub-directories created within that directory inherit the group ownership of the SGID directory. Sub-directories created within the directory will also inherit the SGID special permission propagating this behavior further. Note that although the group ownership and special SGID bit are inherited, all other permissions for newly created

directories are determined in the usual fashion using the value of the umask.

Special Permissions on Directories: Sticky Bit

Based on standard Unix filesystem permissions behavior, a user that has write access to a directory will be able to delete files in that directory (even if the file's permissions do not grant them access). With the sticky bit set on a directory, this behavior is overridden and only users who have at least write access to a file will be able to delete it.

The

/tmp

directory is an example of a directory with the sticky bit set. It is very important for all users to be able to write to the

/tmp

directory, but it could cause major problems if any user could delete any other user's files.

(22)

User Private Group Scheme

UPG provides a convenient way to share files when working in a group project directory

Still does not compromise security of files outside of the group shared project directory

UPG scheme implemented by:

1. placing each user in their own private group 2. setting the umask to0002

3. setting the group ownership of the project directory to a commonly shared GID

4. setting the project directory SGID

User Private Group Scheme

Traditionally Unix systems have placed all users into the same default group. Files are created with the default group, so all users have access to each other's files via common group membership. To

protect users from each other, a default umask of

0022

is used so

that only the owner has write access. The problem with this approach is that there is no easy way to share files with a group.

Imagine you create a group named

blue

for working on a new

project. You could make a special directory with the SGID bit set and the group set to

blue

, so that any files created within will be owned by the group

blue

. Even though the files will be set to the right group, your umask will set the group permission to read only. You are forced to change the permissions on all the files manually, or change your umask (and remember to change it back!) each time you create files for the group.

Enter the User Private Group (UPG) scheme. Your default group is a private group for you. This allows you to safely use a umask of

0002

. All your files will allow read/write access for the default group, but since you are the only member of the group this is ok.

[RHEL5.4] The following applies to RHEL5.4 only:

Out of the box, RHEL5.4 implements the UPG scheme. When creating new user accounts, each user is placed into a private primary group.

[SLES11] The following applies to SLES11 only:

By default, SLES11 do not use the UPG scheme. A new users'

primary group is the

users

group.

[U804] The following applies to U804 only:

Though U804 implements the UPG scheme, the

umask

remains

0022

.

When creating new user accounts, each user is placed into a private primary group.

(23)

Lab 1

Estimated Time: 25 minutes

Task 1: Files and Directories

Page: 1-18 Time: 5 minutes

Requirements: b (1 station) d (graphical environment)

Task 2: Disk and Filesystem Usage

Requirements: b (1 station) d (graphical environment)

Task 3: File and Directory Ownership and Permissions

(24)

Objectives

y Navigate directories on the workstation using different techniques. y Display the characteristics of files and directories.

Requirements

b (1 station) d (graphical environment) Relevance

The Linux filesystem has a large number of files and directories. Learning navigation shortcuts will save significant time when working on the command line.

Lab 1

Task 1

Files and Directories

Use

pwd

to see what the current directory is:

1)

$ cd

$ pwd

/home/guru

From

/home/guru/

, use

cd

to change to the root (

/

) directory:

2)

There are multiple ways to accomplish this,

cd ../../

would also have worked.

$ cd /

Display the contents of the root (

/

) directory. The contents of this directory are

3)

the top level directories described in the Filesystem Hierarchy Standard:

$ ls

. . . output omitted . . .

Navigate to the manual directories and list some specific files:

4)

$ cd /usr/share/man/

$ cd man1/

(25)

the letter

g

, in the

/etc/

directory, change to that directory and use the

ls

command:

$ cd /etc/

$ ls -d g*

$ cd X11/

$ ls -l

. . . output omitted . . .

Return to the guru user's home directory,

/home/guru/

, using one of these

6)

commands:

$ cd

$ cd ž

$ cd /home/guru/

$ cd ../../home/guru/

List all files and directories, including hidden ones. All the files and directories

7)

displayed that have a

.

(period) in front of them are referred to as "hidden" files (and/or directories):

$ ls -a

. . . output omitted . . .

Occasionally, you will encounter or need to create file and directory names that

8)

have spaces or special characters. Names like,

file name

and

<file*name>

are two good examples. When working with names like the above, put the names within single quotes (' '). Run these commands to create a new empty file named

test file

and then examine the results:

**$ touch •test file•**

$ ls

(26)

Objectives

y Use the

df

command to see how much hard drive space is being used

by the filesystem(s)

y Use the

du

command to show disk usage of all files in a certain directory.

Requirements

In order to prevent disk full errors and manage data growth, it is important to be able to determine how much free disk space is available and how much is being consumed, both on a filesystem and directory basis.

Lab 1

Task 2

Disk and Filesystem Usage

Check how much disk space is being used on the workstation filesystem(s):

1)

$ df

. . . output omitted . . .

By default, the Linux

df

command displays sizes in 1 kilobyte blocks. This is fine,

2)

but it's not always the easiest way to read disk space usage. Use

df

to show the

filesystem usage in a more readable format:

$ df -h

. . . output omitted . . .

$ df -H

. . . output omitted . . .

What is the difference between

-h

and

-H

? (See the man page for

df

to find the

answer.)

Show the total disk space usage of the

guru

user's home directory and write the

3)

(27)

Use the

du

command again, this time having the output displayed in human

4)

readable format:

$ cd

$ du -h

. . . output omitted . . .

$ du --si

. . . output omitted . . .

(28)

Objectives

y Display, then change, the ownership of some of the files and directories on the workstation.

y Use various commands to display, change and set permissions for the different files and directories on the workstation.

Requirements

Linux has a powerful and flexible filesystem security model. Being able to manage file and directory permissions will enable you to control who has access to files.

Lab 1

Task 3

File and Directory Ownership

and Permissions

See who owns the files and directories in the

guru

user's home directory. Some, if

1)

not all, of the files and directories will be hidden, so make sure to show hidden files and directories also:

$ cd ž

The third column of the output is where the owner of the file or directory is listed. The fourth column contains the group.

$ ls -al

. . . output omitted . . .

Obtain a file listing for the root directory

/

:

2)

$ ls -al /

. . . output omitted . . .

What are the owner and group for the

/bin/

directory?

Practice changing the user and group ownership of a file:

3)

$ su

-[RHEL5.4 SLES11]

Password: makeitso

Õ [RHEL5.4 SLES11]

$ sudo -i

[U804]

(29)

Change the user and group ownership back; this time with a single command.

# chown root:root /var/log/messages

[RHEL5.4 SLES11]

Verify that the user and group ownership is set to

root

.

# chown syslog:adm /var/log/messages

[U804]

Verify that the user is set to

syslog

and the group ownership is set to

adm

.

# ls -l /var/log/messages

-rw--- 1 root root 38465 Feb 16 10:25 /var/log/messages

[RHEL5.4]

-rw-r--- 1 root root 38465 Feb 16 10:25 /var/log/messages

[SLES11]

-rw-r--- 1 syslog adm 38465 Feb 16 10:25 /var/log/messages

[U804]

Create a new group called

lab2

and add the

guru

user to it:

4)

# groupadd lab2

Add user

guru

to the new group.

# usermod -G lab2 guru

[RHEL5.4]

Add user

guru

to the new group.

# usermod -G lab2,dialout,video guru

[SLES11]

Add user

guru

to the new group.

# usermod -G lab2,adm,dialout,cdrom,floppy,audio,dip,video,plugdev,

a

[U804]

fuse,lpadmin,admin guru

Logout of the

root

account.

# exit

logout

Use the

newgrp

command to change the primary group for user

guru

to the group

5)

lab2

. Then create a new file called

test

. Make sure to be logged in as the

guru

user and in the

guru

user's home directory:

$ newgrp lab2

Create a new empty file

$ touch test

$ ls -l test

-rw-r--r-- 1 guru lab2 0 Feb 27 14:26 test

Notice the newly created file is owned by group

lab2

by default (due to the

previous execution of the

newgrp

command).

Examine the permissions of the

test

file just created. Who has the ability to

6)

modify the file? Result:

Change the permissions of the file

test

. Use

chmod

with symbolic notation to

7)

make the file readable, writable and executable by both the owner and the group, and give everyone else no permissions. There are different ways of doing this. Here is one:

(30)

$ chmod ug+rwx test

$ chmod o= test

View the results of changing the permissions.

$ ls -l test

-rwxrwx--- 1 guru lab2 0 Feb 27 14:26 test

Use

chmod

to set the permissions on two directories and everything in them so

8)

that they are only readable, writable and executable by the owner:

$ su

-[RHEL5.4 SLES11]

Password: makeitso

Õ

[RHEL5.4 SLES11]

Since sudo does not require reauthentication for 15 minutes under Red Hat Enterprise Linux, SUSE Linux Enterprise Server and Ubuntu, a user password will not be prompted for (unless it has been more than 15 minutes since last running sudo).

$ sudo -i

[U804]

The

-R

means to operate recursively, changing permissions on everything in any sub-directories of the directories specified on the command line.

# chmod -R go-rwX /usr/share/man/man2

View the newly changed permissions.

# ls -ld /usr/share/man/man2/

# ls -al /usr/share/man/man2/

. . . output omitted . . .

As the

guru

user in another shell (shown here as

[2]

), try viewing chapter 2 of the

9)

intro man

page:

[2]$ man 2 intro

Fails because the current permissions do not permit read access to the

guru

user.

No manual entry for intro

In the shell, running as

root

, restore the permissions to the original values, and

10)

verify in another shell (shown here a [2]) that the chapter 2

intro

manual is viewable:

# chmod -R go+rX /usr/share/man/man2/

# exit

(31)

Use the

umask

command to change the default permissions that are used when

11)

creating a new file or directory:

Change the default permissions for user

guru

to

r---w--w-

.

$ umask 244

Create a new file.

$ touch test1

Examine the permissions on the new file.

$ ls -l test1

-r---w--w- 1 guru lab2 0 Feb 27 11:57 test1

Reset the value of the

umask

to the original setting:

12)

$ umask 002

[RHEL5.4]

$ umask 022

(32)

Chapter

5

WORK ON THE

COMMAND LINE

Content

LPI Objectives Covered . . . 2 Role of Command Shell . . . 3 Shells . . . 4 Shells continued . . . 5 Identifying the Shell . . . 6 Changing the Shell . . . 7 sh: Prompts . . . 8 bash: Bourne Again Shell . . . 9 bash: Command Editing . . . 10 bash: Command Completion . . . 12 Shell/Environment Variables . . . 13 Key Environment Variables . . . 14

Lab Tasks 15

1. Linux Shells . . . 16 2. Shell Variables . . . 20 3. Bash History . . . 22 4. Aliases . . . 25

(33)

LPI Objectives Covered

103.1 Work on the Command Line

103.1 Work on the Command Line (Weight 4)

Candidates should be able to interact with shells and commands using the command line. The objective assumes the bash shell. Key Knowledge Areas:

y Use single shell commands and one line command sequences to perform basic tasks on the command line.

y Use and modify the shell environment including defining, referencing and exporting environment variables.

y Use and edit command history.

y Invoke commands inside and outside the defined path.

The following is a partial list of the used files, terms and utilities:

.

,

(34)

Role of Command Shell

Shell provides user-interface

• access to filesystem

• scriptability for task automation • program launching

• process control interface

Role of Command Shell

Unix systems are designed with the kernel at the center of everything. The kernel handles all communication with devices

attached to the system and is responsible for multitasking processes. Normal users, on the other hand, don't interact directly with the kernel. Instead, they use programs called shells to interact with the systems. Shells provide the user with a way to navigate the

filesystme, launch and manage other programs, and often provide a scripting framework for automating tasks.

In this module, various command-line shells are discussed. These are shells which handle interaction between the user and the kernel when a user is operating at the command line. It is important to realize that when a user is interacting with a graphical environment (i.e GNOME, KDE, etc.) they are using a shell in this environment also (a graphical shell).

(35)

Shells

Bourne Shell (sh) C Shell (csh) Korn Shell (ksh)

Bourne Shell (sh)

The Bourne shell is the de-facto standard for shell scripting. With the exception of the C shell and its derivatives, most shells available (e.g.

ksh

,

bash

,

zsh

) maintain backwards compatibility to the Bourne shell because of this.

The first standard Unix shell was created in 1979 by Stephen Bourne of AT&T

y Most popular shell for shell scripting y Scripting language based on Algol

y Lacks command history, editing, and aliasing y Uses '

$

' as default prompt

y Part of Unix; not available with Linux C Shell (csh)

The C shell was designed as a shell for C programmers, with a scripting language similar enough to the programming language that programmers wouldn't need to learn a second language. While some hardcore C Shell users like this characteristic, most Unix users do scripting in the Bourne shell scripting language because it is simpler and less cryptic.

y Produced as part of Berkeley (BSD) Unix y Created by Bill Joy (former Sun Chief Scientist) y Scripting language loosely based on C

y Offers command history, completion, and aliasing y Offers job control

y Uses "

%

" as default prompt Korn Shell (ksh)

AT&T developed the Korn shell as a response to Berkeley's C Shell which had become popular due to its rich feature set compared to the Bourne shell. While the command line history syntax is different than the C Shell, all the same functionality is there. The Public Domain Korn Shell offers both vi and emacs editing modes; AT&T Korn shell offers only vi editing mode.

y Created by David Korn of AT&T

y Backwards compatible with Bourne shell

y Adds command history, aliasing, command completion, editing and job control

y Distributed with Unix, and separately by AT&T under an open-source license

(36)

Shells continued

Bourne Again Shell (bash) Enhanced C Shell (tcsh) Z Shell (zsh)

Bourne Again Shell (bash)

The

/bin/sh

executable on most Linux systems is really a symbolic link to

/bin/bash

.

The original Bourne shell is part of the commercial Unix distributions so the GNU camp wrote their own implementation of the Bourne shell from scratch and added several improvements.

y GNU drop-in replacement for Bourne shell y Backwards compatible with Bourne shell y Offers command history, aliasing, and editing y Offers job control

y Default shell in most Linux distributions Alternative, Specialized Shells

The list of Unix shells given above is by no means complete. Several other alternative shells exist, and can be grouped into two primary categories: open source alternative to commercial shells, and specialized shells. Two examples of alternative shells are tcsh and zsh:

y Adds command editing, spell-checking

y Better command line completion than

csh

y Maintained under open source licensing Z Shell (zsh)

The Z shell includes all the major features of each of the other shells, and includes many features of its own:

y Can be run in Korn or Bourne shell compatibility mode y Open source / free software

y Strives to be the most feature-rich shell available y Most advanced command-line editing and globbing

(37)

Identifying the Shell

Login shell name stored in $SHELLenvironment variable Identifying the login shell:

$ echo $SHELL

Identifying the current shell:

$ ps -f

Identifying the Shell

When running the

echo $SHELL

command to discover the shell, it only

displays the name of the login shell. For example:

[csh] $ echo $SHELL

/bin/csh

[csh] % ksh

[ksh] $ echo $SHELL

/bin/csh

Using

ps -f

to identify the current shell has its caveats as well. If you have invoked a shell from within another shell, you will see multiple shells listed in the

ps

output. Carefully look at the process ID (PID) and parent process ID (PPID) columns in the output to determine the most recent shell invocation.

(38)

Changing the Shell

Use the shell name to invoke that shell (i.e. typetcsh) Changing login shell permanently

• Edit the/etc/passwdentry for that user • chsh– (change shell) available to normal users

/etc/shellscontains list of allowed shells

Changing the Shell

When you run a shell from within a shell, the original shell continues to run. It merely waits for you to complete your work with the more recently invoked shell. For example, notice how the shells nest:

BOURNE SHELL $ ksh

KORN SHELL $ csh

C SHELL % bash

BASH $ exit

C SHELL % exit

KORN SHELL $ exit

BOURNE SHELL $

Users can use the

chsh

command to modify their shell entry listed in

the

/etc/passwd

file. The

chsh

command will only allow users to change their shell to one of the shells listed in the

/etc/shells

file. This process is shown in the following example:

$ echo $SHELL

/bin/bash

$ cat /etc/shells

/bin/sh

Changing shell for guru.

Password: work

Õ

New shell [/bin/bash]: /bin/tcsh

Shell changed.

$ echo $SHELL

/bin/bash

$ grep guru /etc/passwd

(39)

sh: Prompts

Simple. No bells or whistles liketcshorbash

Prompt is set using thePS1variable

$ PS1="$(hostname) $ " homer $ export PS1

Prompts

The shell prompt is modified by changing the value of the

PS1

environment variable. Because the Bourne shell does not support special characters, people will often use quoted commands to create a more dynamic prompt. For example, you may want to include the current working directory as part of the prompt:

$ PS1=•[ pwd ]$ •

[/home/guru]$ echo $PS1

[ pwd ]$

[/home/guru]$ cd /tmp

[/tmp]$

Pay close attention to the type of quotes used. Notice how the

pwd

command is enclosed in back-quotes, and the entire prompt string is enclosed in single 'forward' quotes to protect it from shell expansion. Some potential subtleties exist here, and a good understanding of quoting and shell parsing is needed to avoid creating problems. Consider the following example (notice the use of the less protective double quotes in place of single quotes):

$ PS1="[ pwd ]$ "

[/home/guru]$ cd /tmp

[/home/guru]$

Why did the prompt not change to reflect the new working directory?

The answer becomes clear if you look at the value of the

PS1

variable:

[/home/guru]$ echo $PS1

[/home/guru]$

The double quotes used in the second example did not prevent the

shell from expanding the back-quoted

pwd

command when the

PS1

variable was first set. So instead of the back-quoted command being present in the prompt string, the result of originally executing the command is.

(40)

bash: Bourne Again Shell

Completely backwards compatible with Bourne shell Adds several enhancements – many from csh/tcsh

• command-line history and completion • aliases

• sophisticated prompt configuration

• both Emacs and vi style command line editing • tilde (ž) as an alias for home directories

bash

The Bash shell was originally created at MIT as part of the GNU project. It is completely backwards compatible with Bourne shell. As with most of the shells mentioned in this chapter, there are several versions of Bash available. Historically, most Linux distributions shipped with a Bash 2.X version. Bash 3.X is the current version, and is now commonly found on new systems. One way to determine what version of the Bash shell you are using is to send the key sequence: Ó¿x, and then Ó¿v which causes Bash to display version information. Alternately, just run

bash

with the

--version

option as shown in the following example:

# bash --version

GNU bash, version 3.00.15(1)-release (i686-redhat-linux-gnu)

#

Ó¿x Ó¿v

(41)

bash: Command Editing

Bash shell offers vi-mode and Emacs-mode command editing

• to set vi editing mode

$ set -o vi

• to set emacs editing mode (default)

$ set -o emacs

vi mode Editing Commands

When set to vi style editing mode, the Bash shell allows you to use

most of the standard

vi

commands when editing at the shell prompt.

While the

vi

command certainly allows you to perform great feats of

editing with relatively few keystrokes, it was not designed with shell editing requirements in mind. The simple things you tend to do at a Bash shell can end up taking too many keystrokes. Like the full

vi

editor,

bash

vi-mode acts as a modal editor with input and control

modes. Move between these two modes just as you would in

vi

:

use Ã to move to control mode, and use some insertion command (i i a a r) to move back to input mode. The small table below lists commands available from input mode:

Command Description

Ù Delete previous character

Ó¿w Erase previous word

Ã Enter control mode

Once you are in control mode, standard

vi

motion (0 b h l w $

etc.) keys can be used to navigate the command line. Deletes and

changes also use standard

vi

key bindings (x d dw d c etc.).

Refer to the text editing chapter for a more complete

vi

and

vim

command reference.

Emacs Mode Editing Commands

Emacs mode is the default editing mode. Most of the commands described in the table below are relative to something called the point. In emacs mode, the point is an imaginary place just to the left of the character the cursor is on. The following page has a table listing the most commonly used emacs mode commands. When reading the descriptions in the table think of forward as "to the right of the point", and backward as "to the left of the point".

(42)

Emacs-mode Editing Commands

Command Description

Ó¿b Move backward one character

Ó¿f Move forward one character

× Delete one character backward

Ó¿d Delete one character forward

Ãb Move one word backward

Ãf Move one word forward

Ã× Kill one word backward

Ãd Kill one word forward

Ó¿y Paste (yank) last item killed

Ó¿a Move to beginning of line

Ó¿e Move to end of line

Ó¿k Kill forward to end of line

Ó¿l Clear the screen, preserving the current command

line being edited/typed

Ó¿u Kill from beginning of line to point

Ó¿p Recall previous command from history list

Ó¿n Move to next command in history list

Ó¿t Transpose two characters on either side of the point

Ãu Change word after point to all capital letters

Ãl Change word after point to all lowercase letters

(43)

bash: Command Completion

Procedure depends on editing mode in use

• Ð for simple completion in emacs mode

• \(from control mode) for simple completion in vi mode

More advanced completion than cshorksh

• supports: command, file / directory name, username, • hostname, and variable name completion.

• attempts to "do the right thing" based on context • highly customizable

Command Completion

When you press the Ð key while in emacs editing mode one of five things will happen:

y If nothing matches the partial typed text, the shell will beep and nothing further will happen.

y If there is a command name in the search path, a function name, or a filename that matches the typed string, the shell will complete it followed by a space. Command name completion is only attempted if the typed text is in a command position (i.e. at the start of a line).

y If a directory matches the typed text, the shell will complete the filename, followed by a slash.

y If there is more than one way to complete the entry, the shell will complete out to the longest common prefix among the matches.

y If the shell just performed the completion listed in the bullet above. A list of all matching choices will be printed.

Bash completion is quite sophisticated and will attempt to perform the appropriate completion based on context and other syntactical clues. You can also force a specific type of completion; for example Ã/ will attempt only filename completion, and ÃÐ will attempt completion only from commands in the history list.

Command Completion Customization

Completion behavior is highly customizable. One way to add lines to modify completion behavior is by adding lines to your

ž/.inputrc

file (configures readline -- a standard library used by Bash to read user input). Lines are added in the form:

set variable value

completion-ignore-case ⇒ If set to

On

, readline performs filename

matching and completion in a case-insensitive fashion. The default is

Off

.

completion-query-items ⇒ This determines when the user is queried

about viewing the number of possible completions. It may be set to any integer value greater than or equal to zero. If the number of possible completions is greater than or equal to the value of this variable, the user is asked whether or not he wishes to view them; otherwise they are simply listed on the terminal. The default is set to

100

.

print-completions-horizontally ⇒ If set to

On

, readline will display completions with matches sorted horizontally in alphabetical order, rather than down the screen. The default is

Off

.

show-all-if-ambiguous ⇒ This alters the default behavior of the

completion functions. If set to

On

, words which have more than one possible completion cause the matches to be listed

(44)

Shell/Environment Variables

Useful in shell scripting

Programs may malfunction if not set ($PATH,$HOME,$USER, etc.) Viewing variables

• set(shell)

• env(environment)

Clearing variables

• unset(shell|environment) • env -u|i command(environment)

Shell Variables

The term shell variables is used to describe all variables currently set within the shell. Running the

set

command will display a list of all shell variables. For a normal interactive shell, these variable/value pairs come from 3 sources:

1. Inherited from the environment when the shell was first invoked.

2. Set by startup files for the shell such as

/etc/profile

,

ž/.bash_profile

,

ž/.bashrc

, etc.

3. Set manually by a user from the shell prompt.

Shell variables are not inherited by processes launched by a shell.

The following example shows how the value of the shell variable

$AGE

is not visible within a new shell. It also shows the use of the

unset

command to destroy a variable:

$ AGE=42; echo $AGE

42 $ bash

bash $ echo $AGE

. . . no output . . .

Environment Variables

The

export

command will make a shell variable an environment variable that will then be inherited by each launched process. A list of

environment variables can be viewed with the

env

command:

$ AGE=42; env | grep ^AGE

$ export AGE

$ env | grep ^AGE

AGE=42

$ bash

bash $ echo $AGE

42

Variables can also be added to the environment inherited by a

process by listing the variable/value pairs on the command line before

the command. The following example shows running the

crontab

command but setting an environment that would cause it to launch an alternate editor running with a Russian locale:

$ LANG=ru_RU EDITOR=gedit crontab -e

To launch a process and suppress the inheritance of particular

LPIC-1 EXAM PREP (COURSE 1)

LPI101 | Student Edition |

LPI101S-R54S11U804-D00

LPI101

LPIC-1 Exam Prep

(course 1)

LPI101

LPIC-1 EXAM

PREP (COURSE 1)

Table of Contents

Chapter

1

MANAGE FILE

PERMISSIONS AND

OWNERSHIP

LPI Objectives Covered

Filesystem Hierarchy Standard

http://www.pathname.com/fhs/

/

/

/bin/

/boot/

/dev/

/etc/

/home/

/lib/

/media/

/mnt/

/opt/

/root/

/sbin/

/srv/

/tmp/

/usr/

/usr/

/var/

/usr/

/usr/

/usr/bin/

/usr/include/

/usr/lib/

/usr/local/

/usr/sbin/

/usr/share/

/var/

/var/

/var/cache/

/var/lib/

/var/local/

/usr/local

/var/lock/

/var/log/

/var/opt/

/opt

/var/run/

/var/spool/

/var/tmp/

Navigating the Filesystem

cd

cd /usr

/usr/

pwd

/home/ftp/pub

/

/

/

/usr/

cd

local/bin

/usr/local/bin/

cd

/root/

.

cd .

cd ..

/home/foo/

cd ..

/home/

/home/meta/cal/jan/

cd ../foo