files directories 2 cs 360 dir2. slide 2 dir2 cs 360, wsu vancouver course topics program...

Files & Directories 2

CS 360

dir2

dir2 CS 360, WSU Vancouver

Course Topics Program development review

Files & Directories

Tool Building

Processes

Networking

OS Implementation

C


Reading For Lectures I/O ... Dir2 Subject: The file system

In Unix Programming Environment:

Chapter 2, The File System2.1 The basics2.2 What's a file2.3 Directories2.3 Permissions2.5 Inodes2.6 The hierarchy2.7 Devices

Chapter 7, Unix System Calls7.1 Low-level I/O7.2 Directories7.3 Inodes

In Unix Systems Programming:

Chapter 2, The File2.1 Access primitives2.4 Errno

Chapter 3, The File in Context3.1 Multi-user environment3.2 Multiple names3.3 Obtaining information

Chapter 4, Directories4.2 User view4.3 Implementation


Agenda

File Permissions

Access Operations

Miscellaneous Topics

Lab assignment

Wrap-up

This week we learn the details of Unix security.


File Permissions A key OS design decision answers security

questions: does the system distinguish between users? how can users share or protect files? are local files different from distant ones? how can system administration be secured?

1 machine1 usera teama department...a company...the world

ease

safety

security promisesecurity scope

A design is always a choice between competing needs


Unix Uses a Simple Approach Each user is unique (and is identified by a "uid")

uid = an integer (/etc/passwd matches your name and your uid) Each user belongs to one or more groups (each identified by a "gid")

gid = an integer (/etc/groups matches group names and gids)

user

sfil

es

linkcount

% ls -l somefile-rw-r--r-- 1 roger cs360 123 Feb 15 somefile

user group size time last mod file namemode bits(u g o)

Files are protected for just three operations ("access modes") ... read - can examine the data write - can change the data execute - can use as a program (regular file)

- can search contents (directory)

... and at for just three identities: user - what the file creator can do ("owner") group - what members of a group can do other - what anyone else can do

= 100= 010= 001rwx

3 bits

= ???000000= 000???000

= 000000???

u g o3 x 3 bits


The Mode Bits Are Used by Some Routines Recall our previous "open for writing" example:

fd = open ("/home/roger/bar", O_WRONLY|O_CREAT|O_TRUNC, 0644);

These bits are used if the file must be created

What access mode value would you use to create a file that was: rw by owner, r by group, no access by anyone else? ___________ rw by owner, no access by group or anyone else? ___________ rw by owner and group, r by anyone else? ___________

The access mode bits are: 110 100 100

rw by user, r by group, r by othernumbers that begin with a "0" are octalrw- r-– r--


Sometimes We Need to Bypass Protection Example: mail program

waiting mail files should be in a directory that is fully protected from users but, the /bin/mail program should be able to manipulate those files

Example: account administration anyone should be able to read /etc/passwd but, only the /bin/passwd program should be able to change that file

Unix uses a patented and powerful mechanism


A Powerful Administrative MechanismThe distinguished uid "superuser" can do anything

change ownership, permissions, ... uid == 0; account name = "root"

% su -password: *****%

be careful!

(gid's for all the groups to which the real uid belongs; we won't consider these)

Administrative programs can operate with a different uid than the invoker real uid -- the uid of the actual human who logged in effective uid -- the uid temporarily for lifetime of process (similarly for gid too, plus "supplementary gids")

% ls -l /bin/mail-rws--x--x 2 mailer bin 40960 Dec 29 1997 /bin/mail*

The effective-uid is changed via "set-user-ID" (set-uid) bit on executables "effective uid" becomes that of the executable owner for duration of process superuser turns on set-uid for trusted programs


Process1

image

context

Processn

image

context

...

code data stack heapavail

• current instruction counter• stack top & frame pointer• heap bottom• scheduling priority• parent process• …

• user & group id's• register values• file descriptors

0: ...1: ...2: ...

real & effective uid & gid

Security State is in the Process

Can't change these values except via process initiation as just described

The kernel checks values when performing services

No way to get around these checks


How the Mechanisms are Applied To open a file for reading, this must be true:

either:– effective uid == 0 (the superuser)

or:– and at least one of these statements must be true about the inode:

– user "read" bit is on && (effective uid == inode uid)– group "read" bit is on && (effective gid == inode gid)– other "read" bit is on

To open for writing is similar (based on "write" bit)

To open for execution is similar (based on "execute" bit)


Directory Access Rules Search rule:

to open a file in a directory, you must have"execute" access to each directory in the full pathname

so the "execute" bit on a directory is often called the "search" bit Write rule:

to create or delete a file in a directory, you must have"write" access to the the directory

Read rule: to find the names of the files in a directory, you must have

"read" access to the directory (e.g. "ls" command)

% ls -ld /class/cs360drwxr-x--- 4 ray cs360 8192 Feb 5 16:43 /class/cs360

Consider this example:

• can one of you look inside that directory? _______• can someone not in the class do that? _______• can you create a file? _______• can you delete a file? _______


Access Operations

Status operations Mode operations Creation mode rules Link and delete operations

Now we will discuss how tomanipulate the file permissions


Getting Status of a File The "stat" functions return a structure that tells you everything about a file:

notice the "st_" naming convention for the fields the "st_mode" field is the one you will use most don't make assumptions about the implementation of these types don't make assumptions about the order of the fields

struct stat { ino_tst_ino; /* inode */nlink_t st_nlink; /* link count */uid_tst_uid; /* uid */gid_tst_gid; /* gid */mode_t st_mode; /* mode bits */time_t st_atime; /* last access */ time_t st_ctime; /* creation */ time_t st_mtime; /* last mod */ off_tst_size; /* size */ off_tst_blksize; dev_tst_dev; dev_tst_rdev;

};

<sys/stat.h>


Getting Status of a File The header file also has useful defines:

#define S_IRUSR 00400#define S_IWUSR 00200#define S_IXUSR 00100

#define S_IRGRP 00040#define S_IWGRP 00020#define S_IXGRP 00010

#define S_IROTH 00004#define S_IWOTH 00002#define S_IXOTH 00001

#define S_ISREG(m) (((m) & 0xf000) == 0x0000)#define S_ISDIR(m) (((m) & 0xf000) == 0x3000)

<sys/stat.h>

struct stat *s;

... initialize s somehow for a particular file ...

if (s->st_mode && S_IRUSER) ... user can read this file ...if (S_ISREG(s->st_mode)) ... this is a regular file ...

Examples:we will see how later ...


How To Use the Stat Function Example to get status of

"/home/roger/foo":#include <sys/stat.h>

struct stat area, *s = &area;

if (stat ("/home/roger/foo", s) == 0) {

if (S_ISREG (s->st_mode)) {... it's a regular file ...

} else if (S_ISDIR (s->st_mode)) {... it's a directory ...

} else {... it's a pipe, terminal, etc. ...

}

} else {... file doesn't exist or can't get to it ...

}

what is going on here?

and here?

and here?

"special" files; we won't discuss much

Note: "stat" takes pathnames, "fstat" takes file descriptors "lstat" doesn't follow symbolic links


Let's Code the "isDirectory" Routine ... Usage

: #include <cs360/misc.h>...if (isDirectory ("/home/roger/one")) {

... it's a directory! ...} else {

... it's a regular file! ...}

Implementation:#include <sys/stat.h>

int isDirectory (char *pathname) {

struct stat area, *s = &area;

return (stat (pathname, s) == 0) && S_ISDIR (s->st_mode);

}


Changing File Access Permissions Use the "chmod" (change mode) function to change access modes:

you must own the inode or be superuser

#include <sys/stat.h>...mode_t newMode = S_IRUSR | S_IWUSR;...if (chmod ("/home/roger/foo", newMode) < 0) {

... file doesn't exist or we don't have permission ...}

% chmod u=rw /home/roger/foo% chmod go+r /home/roger/bar

The "chmod" command does the same thing:

mode syntax is [ugo][=+-][rwx]

"chown" is similar and changes ownership see text book and man pages (little used)


Need Modes When Making a Directory Use "mkdir" to create a directory:

why this choice of mode value?

#include <sys/stat.h>...char *name = "/home/roger/abc";mode_t mode = S_IRUSR | S_IWUSR | S_IXUSR | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH;...if (mkdir (name, mode) < 0) {

... handle error ...}...

Note: Use "rmdir" to remove a directory:

the directory must be empty (except for . and .. entries)

status = rmdir (name);


Key Unix Design Decisions to Remember

This design has proven remarkably convenient, powerful, and reliable

One inode for each file (actually, the inode DEFINES the file) File name and directory ARE NOT in inode File ownership and access permissions ARE in inode Permissions are structured 3x3 (operations x identities) Permissions can be circumvented only in a structured

manner using superuser and set-uid concepts


Summary of Design Consequences ... Directories reference files only through inode numbers

moving files between directories is very fast (and atomic) Two directories can include the same inode number

a file can be shared, appearing in several places with same or different name also, no special cases for "shortcuts" etc.

Space is reclaimed only when link count & open count are both 0 removing a file may not create free space files can't disappear while a process is working on them also, no special cases for "sharing violation" etc.

An inode number is unique only within a file system files can't span partitions or disks, or be moved to new disks and, files can't be bigger than a single physical disk

Files don't have "type" (beyond regular vs. directory) no optimizations for databases, no self-identifying objects, no new types but, easy to code general programs such as "cp", "mv", "clone1"

File security information is in the inode data is protected even when files are shared or moved


Summary The Unix design is notable for it's simplicity:

Unix makes no distinction between binary and text files Unix files are implemented using fixed size blocks Unix protects files for three kinds of operations and three kinds of identities

The Unix file system has several design innovations: inodes & links uid & gid identifiers superuser & set-uid programs

The Unix design is used as a reference by most other operating systems The Unix design decisions make some operations very fast & convenient,

but several emerging issues are perhaps not well addressed clipboard, MIME, database support, media-centric apps

A file system is a key OS design decision providing userswith specific advantages and disadvantages

File system design continues to be a key research topic no best approach!

Uni

xIn

gen

eral


Lab Assignment – dir2 Write program readable

Takes one or zero command line arguments. Argument, if present, is a pathname (relative or absolute). If no argument is present, the pathname of the present working directory is assumed (getcwd).

Readable recursively traverses the directories and their files, starting with the pathname, and lists every regular file that is readable by the current process.

Each regular file is listed to stdout as a full pathname, one pathname per line.

No order is defined for the pathnames that are output. Other stuff:

Ignore symbolic links (Why?) Submit one source file via email: readable.c Design your solution in advance of coding. You will need: access, opendir, readdir, closedir, lstat

files directories 2 cs 360 dir2. slide 2 dir2 cs 360, wsu vancouver course topics program...

Documents