Опубликован: 06.08.2012 | Уровень: специалист | Доступ: платный
Лекция 10:

File systems and devices

< Лекция 9 || Лекция 10: 1234 || Лекция 11 >
Making a program executable

File permissions enable one problem that occurs so often that it's worth drawing attention to it. Many operating systems require that an executable program have a special naming convention, such as COMMAND.COM or FOO.BAT which in MS-DOS denotes a specific kind of binary executable and a script file, respectively. In UNIX, executable programs don't need a special suffix, but they must have the x bit set. Sometimes this bit gets reset (turned off), for example if you copy it across the Net with ftp. The result looks like this:

$ ps
bash: ps: Permission denied $ ls -l /bin/ps
-r--r--r--  1 bin  kmem  163840 May 6 06:02 /bin/ps
$ su                             you need to be super user to set ps permission
Password:                        password doesn't echo
# chmod +x /bin/ps               make it executable
# ps                             now it works
PID  TT     TIME  COMMAND
226  p2  0:00.56  su (bash)
239  p2  0:00.02  ps
146  v1  0:00.06  /usr/libexec/getty Pc ttyv1
147  v2  0:00.05  /usr/libexec/getty Pc ttyv2
# ^D                             exit su
$ ps
ps: /dev/mem: Permission denied  hey! it’s stopped working

Huh? It only worked under su and stopped working when I became a mere mortal again? What's going on here?

There's a second problem with programs like ps: some versions need to be able to access special files, in this case /dev/mem, a special file that addresses the system memory. To do this, we need to set the setgid bit, s, which requires becoming super user again:

$ su                  you need to be super user to set ps permission
Password:             password doesn't echo
# chmod g+s /bin/ps   set the setgid bit
# ls -l /bin/ps       see what it looks like
-r-xr-sr-x  1 bin  kmem  163840 May   6 06:02 /bin/ps
# ^D                  exit su
$ ps                  now it still works
PID  TT  STAT     TIME  COMMAND
226  p2  S     0:00.56  su (bash)
239  p2  R+    0:00.02  ps
146  v1  Is+   0:00.06  /usr/libexec/getty Pc ttyv1
147  v2  Is+   0:00.05  /usr/libexec/getty Pc ttyv2

In this example, the permissions in the final result really are the correct permissions for ps. It's impossible to go through the permissions for every standard program. If you suspect that you have the permissions set in correctly, use the permissions of the files on the Live File system CD-ROM as a guideline.

setuid and setgid programs can be a security issue. What happens if the program called ps is really something else, a Trojan Horse? We set the permissions to allow it to break into the system. As a result, FreeBSD has found an alternative method for ps to do its work, and it no longer needs to be set setgid.

Mandatory Access Control

For some purposes, traditional UNIX permissions are insufficient. Release 5.0 of FreeBSD introduces Mandatory Access Control, or MAC, which permits loadable kernel modules to augment the system security policy. MAC is intended as a toolkit for developing local and vendor security extensions, and it includes a number of sample policy modules, including Multi-Level Security (MLS) with compartments, and a number of augmented UNIX security models including a file system firewall. At the time of writing it is still considered experimental software, so this book doesn't discuss it further. See the man pages for more details.

Links

In UNIX, files are defined by inodes structures on disk that you can't access directly. They contain the meta data, all the information about the file, such as owner, permissions and timestamps. What they don't contain are the things you think of as making up a file: they don't have any data, and they don't have names. Instead, the inode contains information about where the data blocks are located on the disk. It doesn't know anything about the name: that's the job of the directories.

A directory is simply a special kind of file that contains a list of names and inode numbers: in other words, they assign a name to an Inode, and thus to a file. More than one name can point to the same inode, so files can have more than one name. This connection between a name and an inode is called a link sometimes confusingly hard link. The inode numbers relate to the file system, so files must be in the same file system as the directory that refers to them.

Directory entries are independent of each other: each points to the Inode, so they're completely equivalent. The inode contains a link count that keeps track of how many directory entries point to it: when you remove the last entry, the system deletes the file data and metadata.

Alternatively, symbolic links sometimes called soft links, are not restricted to the same file system (not even to the same system!), and they refer to another file name, not to the file itself. The difference is most evident if you delete a file: if the file has been hard linked, the other names still exist and you can access the file by them. If you delete a file name that has a symbolic link pointing to it, the file goes away and the symbolic link can't find it anymore.

It's not easy to decide which kind of link to use—see UNIX Power Tools (O'Reilly) for more details.

Directory hierarchy

Although Microsoft platforms have a hierarchical directory structure, there is little standardization of the directory names: it's difficult to know where a particular program or data file might be. UNIX systems have a standard directory hierarchy, though every vendor loves to change it just a little bit to ensure that they're not absolutely compatible. In the course of its evolution, UNIX has changed its directory hierarchy several times. It's still better than the situation in the Microsoft world. The most recent, and probably most far-reaching changes, occurred over ten years ago with System V.4 and 4.4BSD, both of which made almost identical changes.

Nearly every version of UNIX prefers to have at least two file systems, / (the root file system) and /usr even if they only have a single disk. This arrangement is considered more reliable than a single file system: it's possible for a file system to crash so badly that it can't be mounted anymore, and you need to read in a tape backup, or use programs like fsck or fsdb to piece them together. We have already discussed this issue on page 68, where I recommend having /usr on the same file system as /.

Standard directories

The physical layout of the file systems does not affect the names or contents of the directories, which are standardized. Table 10-2 gives an over view of the standard FreeBSD directories; see the man page hier(7) for more details.

Таблица 10.2. FreeBSD directory hierarchy
Directory name Usage
/ Root file system. Contains a couple of system directories and mount points for other file systems. It should not contain anything else.
/bin Executable programs of general use needed at system startup time. The name was originally an abbreviation for binary,but many of the files in here are shell scripts.
/boot Files used when booting the system, including the kernel and its associated klds.
/cdrom Amount point for CD-ROM drives.
/compat A link to /usr/compat: see below.
/dev Directory of device nodes. The name is an abbreviation for devices. From FreeBSD 5.0 onward, this is normally a mount point for the device file system, devfs. We'll look at the contents of this directory in more detail on page 195.
/etc Configuration files used at system startup. Unlike System V, /etc does not contain kernel build files, which are not needed at system startup. Unlike earlier UNIX versions, it also does not contain executable—they have been moved to /sbin.
/home By convention, put user files here. Despite the name, /usr is for system files.
/mnt A mount point for floppies and other temporary file systems.
/proc The process file system. This directory contains pseudo-files that refer to the virtual memory of currently active processes.
/root The home directory of the user root. In traditional UNIX file systems, root's home directory was /, but this is messy.
/sbin System executable needed at system startup time. These are typically system administration files that used to be stored in /etc.
/sys If present, this is usually a symbolic link to /usr/src/sys, the kernel sources. This is a tradition derived from 4.3BSD.
/tmp A place for temporary files. This directory is an anachronism: normally it is on the root file system, though it is possible to mount it as a separate file system or make it a symbolic link to /var/tmp. It is maintained mainly for programs that expect to find it.
/usr The "second file system." See the discussion above.
/usr/XllR6 The X WindowSystem.
/usr/XllR6/bin Executable X11 programs.
/usr/XllR6/include Header files for X11 programming.
/usr/XllR6/lib Library files for X11.
/usr/XllR6/man Man pages for X11.
/usr/bin Standard executable programs that are not needed at system start. Most standard programs you use are stored here.
/usr/compat A directory containing code for emulated systems, such as Linux.
/usr/games Games.
/usr/include Header files for programmers.
/usr/lib Library files. FreeBSD does not have a directory /lib.
/usr/libexec Executable files that are not started directly by the user, for example the phases of the C compiler (which are started by /usr/bin/gcc)or the getty program, which is started by init.
/usr/libdata Miscellaneous files used by system utilities.
/usr/local Additional programs that are not part of the operating system. It parallels the /usr directory in having subdirectories bin, include, lib, man, sbin, and share. This is where you can put programs that you get from other sources.
/usr/obj Object files created when building the system. See "Chapter 33" .
/usr/ports The Ports Collection.
/usr/sbin System administration programs that are not needed at system startup.
/usr/share Miscellaneous read-only files, mainly informative. Subdirectories include doc, the FreeBSD documentation, games, info, the GNU info documentation, locale, internationization information, and man, the man pages.
/usr/src System source files.
/var A file system for data that changes frequently, such as mail, news, and log files. If /var is not a separate file system, you should create a directory on another file system and symlink /var to it.
/var/log Directory with system log files
/var/mail Incoming mail for users on this system
/var/spool Transient data, such as outgoing mail, print data and anonymous ftp.
/var/tmp Temporary files.
< Лекция 9 || Лекция 10: 1234 || Лекция 11 >
Бехзод Сайфуллаев
Бехзод Сайфуллаев
Узбекистан, Бухара, Бухарский институт высоких технологий, 2013
Василь Остапенко
Василь Остапенко
Россия