Download H 10.3. File-System Interface

Operating System Principles
AUA CIS331
Albert Minasyan
Handout 11
File System Interface
11.4. File System mounting
11.5. File Sharing
11.5.1. Multiple Users
Owner Group approach
UID in Unix, SID in Windows
11.6. Protection
11.6.1. Types of access
Silberschatz, 6th or 9th ed. Chapters 11.
11.4. File System Mounting
Just as a file must be opened before it is used, a file system must be mounted before it can be available
to processes on the system. More specifically, the directory structure can be built out of multiple
partitions, which must be mounted to make them available within the file system name space.
The mount procedure is straightforward. The operating system is given the name of the device, and
the location within the file structure at which to attach the file system (or mount point). Typically, a
mount point is an empty directory at which the mounted file system will be attached. For instance, on
a UNIX system, a file system containing user's home directories might be mounted as home; then, to
access the directory structure within that file system, one could precede the directory names with
/home, as in /home/jane. Mounting that file system under /users would result in the path name
/users/jane to reach the same directory.
To illustrate file mounting, consider the file system depicted in Figure below, where the triangles
represent subtrees of directories that are of interest. In Figure (a), an existing file system is shown,
while in Figure (b), an unmounted partition residing on /device/dsk is shown. At this point, only the
files on the existing file system can be accessed.
In Figure 10.13, the effects of the mounting of the partition residing on /device/dsk over /users are
shown. If the partition is unmounted, the file system is restored to the situation depicted in Figure
10.12.
Figure 11.15 Mount point.
Figure 11.14 File system. (a) Existing system. (b) Unmounted volume.
The Microsoft Windows family of operating systems (95,98, NT, and 2000) maintains an extended
two-level directory structure, with devices and partitions assigned a drive letter. Partitions have a
Operating System Principles
AUA CIS331
Albert Minasyan
general graph directory structure associated with the drive letter. The path to a specific file is
then in the form of drive-letter:\path\to\file. These operating systems automatically discover all
devices and mount all located file systems at boot time. In some systems, like UNIX, the mount
commands are explicit. A system configuration file contains a list of devices and mount points for
automatic mounting at boot time, but other mounts may be executed manually.
Mounting Floppy Disk to the mount point /mnt/floppy
1. Place msdos formatted floppy disk into floppy disk drive. If you use Virtual Machine then copy
the file Academic Server - /_classes/CIS255/Programs/VPC_DiskImageManager/floppy.vfd
to the directory where your virtual machine hard disk image resides.
2. Attach the virtual floppy disk image to your Virtual Machine: Option “Floppy”, Capture Floppy
Disk image, select floppy.vfd file.
3. Perform the following commands:
mount –t msdos /dev/fd0 /mnt/floppy General Form - mount device /dev/fd0
with the “msdos” type of filesystem on /mnt/floppy mount point (directory) of Linux tree.
mount /mnt/floppy
tree /mnt/floppy
tree /mnt/floppy/
-
simple form of mounting
look what is on floppy disk
/mnt/floppy/
`-- sendmail.cf
0 directories, 1 file
mkdir /mnt/floppy/homeworks
cp /etc/services /mnt/floppy/homeworks
-
create directory on floppy disk
copy the file to floppy disk
/mnt/floppy/
|-- homeworks
|
`-- services
`-- sendmail.cf
df -k
Filesystem
/dev/hda1
none
/dev/fd0
1k-blocks
2016016
63320
1423
Used Available Use% Mounted on
1348384
565220 71% /
0
63320
0% /dev/shm
46
1378
4% /mnt/floppy
Two forms of dismounting umount /dev/fd0 or umount /mnt/floppy
umount /mnt/floppy
tree /mnt/floppy/
/mnt/floppy/
0 directories, 0 files
- make inaccessible the floppy disk before removing
the disk from the drive (this is mandatory to save the
information on the FDD from cache).
Operating System Principles
AUA CIS331
Albert Minasyan
11.5. File Sharing
Once multiple users are allowed to share files, the challenge is to extend sharing to multiple file
systems, including remote file systems. Finally, there can be several interpretations of conflicting
actions occurring on shared files. For instance, if multiple users are writing to the file, should all the
writes be allowed to occur, or should the operating system protect the user actions from each other?
11.5.1. Multiple Users
When an operating system accommodates multiple users, the issues of file sharing, file naming, and
file protection become preeminent. Given a directory structure that allows files to be shared by users,
the system must mediate the file sharing. The operating system either can allow a user to access the
files of other users by default, or it may require that a user specifically grant access to the files.
[root@linuxhost home]#
.
|-- student1
|
`-- textfile.txt
`-- student2
`-- temp
|-- edit
|-- edit1
`-- text.txt
tree
Default
Access
User Specific
Access
Student1
Student2
The Home Directories of Windows Users
Owner Group Approach
These are the issues of access control and protection, which are covered below. To implement sharing
and protection, the system must maintain more file and directory attributes than on a single-user
system. Although there have been many approaches to this topic historically, most systems have
evolved to the concepts of file/directory owner (or user) and group. The owner is the user who may
change attributes, grant access, and has the most control over the file or directory. The group attribute
of a file is used to define a subset of users who may share access to the file. For example, the owner of
a file on a UNIX system may issue all operations on a file, while members of the file's group may
execute one subset of those operations, and all other users may execute another subset of operations.
Exactly which operations can be executed by group members and other users is definable by the file's
owner.
Operating System Principles
AUA CIS331
Albert Minasyan
We need More Directory Attributes
Users
Groups
The group attribute of
a file is used to define
a subset of users who
may share access to
the file
Permissions
Ownership
The owner is the user who:

may change attributes

grant access

has the most control over the file or directory.
Groups
The group attribute of a file is
used to define a subset of
users who may share access
to the file
-rw-r--r--
1 student1
CIS1group
1 2
5
7
Group owner
3
4
6
User owner
Protection
Ownership
124
Aug 24 11:00
.bashrc
8
9
file size last modific.date
10
file name
Operating System Principles
AUA CIS331
Albert Minasyan
UID in Unix, SID in Windows
Most systems implement owner attributes by managing a list of user names and associated user
identifiers (user IDS). In Windows NT parlance, this is a Security ID (SID). These numerical IDS
are unique, one per user. When a user logs in to the system, the authentication stage determines the
appropriate user ID for the user. That user ID is associated with all of the user's processes and threads.
When they need to be user readable, they are translated back to the user name via the user name list.
Likewise, group functionality can be implemented as a system-wide list of group names and group
identifiers. Every user can be in one or more groups, depending upon operating system design
decisions. The user's group IDS are also included in every associated process and thread.
Usernames
Security ID
Username
Security Identifier (SID) in windows = User Identifier (UID) in Unix

These numerical identifiers are unique.

Every user can be in one or more groups.

Groups also have Group Identifiers (GID) and Group Names.

After user login and authentication the User ID and Group ID are determined (by



username and password).
That User IDs are associated with all of the User’s processes and files.
The GIDs also are included in any process or file association.
The OS uses only numerical IDs. Names are for people (to show on the screen, to print).
User name
/etc/passwd file keeps Usernames, UIDs of Unix system
student1:x:501:501::/home/stud1:/bin/bash
student2:x:502:502::/home/stud2:/bin/bash
Group ID (primary)
User ID
Operating System Principles
AUA CIS331
Albert Minasyan
Group ID
/etc/group file keeps Group Names, GIDs of Unix system
student1:x:501:
student2:x:502:
cis215group:x:503:student1,student2
Group Members
The owner and group IDS of a given file or directory are stored with the other file attributes. When a
user requests an operation on a file, the user ID can be compared to the owner attribute to determine if
the requesting user is the owner of the file. Likewise, the group IDS can be compared. The result
indicates which permissions are applicable. The system then applies those permissions to the
requested operation, and allows or denies it.
Student2
Runs vi command from vi
executable binary file
-rwxr-xr-x
1 root
student2
1277
1319
root
124
0 Feb11 tty3
Aug 24 11:00
vi
vi becomes a process with the
Student2 user’s permissions even it
has root, root - owner, group
00:00:00 vi
Effective User ID of Process
root
root
root
root
root
root
root
student1
student2
student2
711
713
714
715
716
719
1189
1197
1277
1319
1
1
1
1
1
711
1
1189
713
0
0
0
0
0
0
0
0
0
1277
Feb11
Feb11
Feb11
Feb11
Feb11
Feb11
Feb11
Feb11
Feb11
tty1
tty3
tty4
tty5
tty6
tty1
tty2
tty2
tty3
0 Feb11 tty3
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
login -- root
login -- student2
/sbin/mingetty tty4
/sbin/mingetty tty5
/sbin/mingetty tty6
-bash
login -- student1
-bash
-bash
00:00:00 vi
Now this process can access the files accessible for
Student2 user.
It can only read the .bashrc file below because .bashrc
group owner contains as a member the Student2 user.
-rw-r--r-1 student1 CIS215group
124
/etc/group file content
cis215group:x:503:student1,student2
Aug 24 11:00
.bashrc
Operating System Principles
AUA CIS331
Albert Minasyan
Process User Identifiers in Windows
The user information within a process can be used for other purposes as well. One process may
attempt to interact with another process, and user information can dictate the result, based on the
design of the operating system. For example, a process may attempt to terminate, background, or
lower the priority of another process. If the owner of each process is the same, then the command may
succeed, or else it may be denied. It may also be allowed to succeed if it is owned by the privileged
user.
Process interaction with different permissions
root
root
root
root
root
root
root
student1
student2
student2
Can Kill
711
713
714
715
716
1
1
1
1
1
719
1189
1197
1
1189
1277
1319
1277
0
0
0
0
0
Feb11
Feb11
Feb11
Feb11
Feb11
711
tty1
tty3
tty4
tty5
tty6
0 Feb11 tty1
0 Feb11 tty2
0 Feb11 tty2
713
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00 -bash
00:00:00 login -- student1
00:00:00 -bash
0 Feb11 tty3
0 Feb11 tty3
login -- root
login -- student2
/sbin/mingetty tty4
/sbin/mingetty tty5
/sbin/mingetty tty6
00:00:00 -bash
00:00:00 vi
Cannot Kill
Operating System Principles
AUA CIS331
Albert Minasyan
11.6. Protection
When information is kept in a computer system, we want to keep it safe from physical damage
(reliability) and improper access (protection).
The need to protect files is a direct result of the ability to access files. Systems that do not permit
access to the files of other users do not need protection. Thus, we could provide complete protection
by prohibiting access. Alternatively, we could provide free access with no protection. Both approaches
are too extreme for general use. What is needed is controlled access.
[root@linuxhost home]# tree
.
Controlled
|-- student1
Access
|
`-- textfile.txt
`-- student2
Full Access
`-- temp
No Protection
|-- edit
|-- edit1
`-- text.txt
Student1
Student2
No Access
Full Protection
11.6.1. Types of Access
Protection mechanisms provide controlled access by limiting the types of file access that can be made.
Access is permitted or denied depending on several factors, one of which is the type of access
requested. Several different types of operations may be controlled:






Read: Read from the file.
Write: Write or rewrite the file.
Execute: Load the file into memory and execute it.
Append: Write new information at the end of the file.
Delete: Delete the file and free its space for possible reuse.
List: List the name and attributes of the file.
Operating System Principles
AUA CIS331
Albert Minasyan
11.6.2. Access Control
The most common approach to the protection problem is to make access dependent on the identity of
the user. Various users may need different types of access to a file or directory. The most general
scheme to implement identity-dependent access is to associate with each file and directory an accesscontrol list (ACL) specifying the user name and the types of access allowed for each user. When a user
requests access to a particular file, the operating system checks the access list associated with that file.
If that user is listed for the requested access, the access is allowed. Otherwise, a protection violation
occurs, and the user job is denied access to the file.
This approach has the advantage of enabling complex access methodologies. The main problem with
access lists is their length. If we want to allow everyone to read a file, we must list all users with read
access.
This technique has two undesirable consequences:


Constructing such a list may be a tedious and unrewarding task, especially if we do not know in
advance the list of users in the system.
The directory entry, previously of fixed size, now needs to be of variable size, resulting in more
complicated space management.
These problems can be resolved by use of a condensed version of the access list.
To condense the length of the access control list, many systems recognize three classifications of users
in connection with each file:
 Owner: The user who created the file is the owner.
 Group: A set of users who are sharing the file and need similar access is a group, or work group.
 Universe: All other users in the system constitute the universe.
The most common recent approach is to combine access control lists with the more general (and easier
to implement) owner, group, and universe access control scheme that was described above.
Another approach to the protection problem is to associate a password with each file. Just as access to
the computer system is often controlled by a password, access to each file can be controlled by a
password. If the passwords are chosen randomly and changed often, this scheme may be effective in
limiting access to a file to only those users who know the password.