|
Problem 5-1 |
|
|
Give 5 different path names for the file /etc/passwd. ./passwd ../passwd etc/passwd ./etc/passwd ../etc/passwd |
|
|
Problem 5-3 |
|
|
Some operating systems provide a system call RENAME to give a file a
new name. Is there any difference at all between using this call to
rename a file, and just copying the file to a new file with the new
name, followed by deleting the old one? The difference is only apparent on a system-level. The end effect (same file, different name) will be the same. However, by copying and deleting, new file blocks are allocated whereas merely renaming will alter the directory entry of the file. Excessive copying of files can have unexpected consequences when repeated often. The most obvious is fragmentation. This occurs when a large file is split into smaller segments as there is not enough contiguous free space for the entire file. It stands to reason that the more often when create and delete files, the greater the likely hood of this happening is. |
|
|
Problem 5-7 |
|
|
Free disk space can be kept track of using a free list or a bit map. Disk
addresses require D bits. For a disk with B blocks, F of
which are free, state the condition under which the free list uses less space
than the bit map. For D having the value 16 bits, express your answer as
a percentage of the disk space that must be free. We will assume block sizes of 1K. In terms of D, F and B, the formulae are as follows: Free List Size (in bits): (F*1024)*DBit Map Size (in bits): B*1024Thus the Free List will use less memory if F*D&leB. If D=16, the ratio of F to B is 1/16. This is equivalent to 6.25% disk free space. |
|
|
Problem 5-9 |
|
|
The performance of a file system depends critically on the cache hit rate
(fraction of the blocks found in the cache). If it takes 1 msec to satisfy a
request from the cache, but 40 msec to satisfy a request if a disk read is
needed, give a formula for the mean time required to satisfy a request if the hit
rate is h. Plot this function for h:(0,1) The mean time is calculated as the probability of a hit times the time required to proccess a hit plus the probability of a miss times the time required to proccess a miss or: 1 msec * h + (1 - h) * 40 msec![]() |
|
|
Problem 5-10 |
|
|
A floppy disk has 40 cylinders. A seek takes 6 msec per cylinder moved. if
no attempt is made to put the blocks of a file close to each other, two blocks
that are logically consecutive (i.e., follow one another in the file) will be
about 13 cylinders apart on average. If, however, the operating system makes an
attempt to cluster related blocks, the mean interblock distance can be reduced to
2 cylinders (for example). How long does it take to read a 100 block file in
both cases, if the rotational latency is 100 msec and the transfer time is 25
msec per block? It takes 25 msec to transfer one block, thus transferring 100 blocks takes 2500 msec. If the average number of cylinders to move is 13, then at 6 seconds per cylinder this will take 7800 seconds for a 100 block file. Lastly, the rotational latency is 100 msec and is added for every block, thus total is 10,000 msec. Thus the non-optimized solution for this problem is 2,500 + 7,800 + 10,000 = 20,300 msec to transfer a 100 block file. Optimization only alters the mean interblock distance to 2 cylinders and thus reduced 7,800 to 1,200 msec. Thus the total time for an optimized disk is 13,700 msec. |
|
|
Problem 5-13 |
|
|
After getting your degree, you apply for a job as director of a large
university computer center that has just put its ancient operating system out to
pasture and switched over to UNIX. You get the job. Fifteen minutes after
starting work, your assistant bursts into your office screaming: "Some students
have discovered the algorithm we use for encrypting passwords and posted it to
the bulletin board." What should you do? Relax and get yourself a cup of coffee. Real security is not based upon obfuscation and thus, the knowledge of the encryption algorithm will be of little assistance in cracking passwords. |
|
|
Problem 5-15 |
|
A computer science department has a large collection of UNIX machines on its
local network. Users on any machine can issue a command of the formmachine4 whoand have it executed on machine4 without having the user login on the remote machine. This feature is implemented by having the user's kernel send the command and his uid to the remote machine. Is this scheme secure if the kernels are all trustworthy (e.g., large time-shared minicomputers with protection hardware)? What if some of the machines are students' personal computers, with no protection hardware? This is not a secure system. Consider the following scenario: A student connects his/her laptop to an extra network node and starts listening for packet signals. Intercepting a signal from a sysadmin, he/she then changes the information in the packet to a command such as useradd jondoe -G:0.
The security of the system can then be compromised without much trouble. This
sort of crack would be even easier if students' machines were normall connected
to the network.
|
|
|
Problem 5-16 |
|
|
When a file is removed, its blocks are generally put back on the free list,
but they are not erased. Do you think it is a good idea to have the operating
system erase each block before releasing it? Consider both security and
performance factors in your answer, and explain the effect of each. The additional disk writes required by erasing each block mean that, while security is greater, performance is less. An acceptable compromise might be to have a separate utility for removing confidential information as opposed to your web-browser cache. |
|
|
Problem 5-20 |
|
|
Two Computer Science majors, Carolyn and Elinor are having a discussion about
i-nodes in MINUX, Carolyn maintains that memories have gotten so large and so
cheap that when a file is opened, it is sipler and faster just to fetch a new
copy of the i-node into the i-node table, rather than search the entire table to
see if it is already there. Elinor disagrees. Who is right? I will side with Elinor on this issue. Carolyn is saying is that people should buy tons of memory and assign lots of it to the cache. This is wrong. The reason for having a cache in the first place is that disks are much slower than memory. Thus, unless Carolyn's system has a very fast disk drive, it will still be better to search the table for the i-node entry. Second, assigning more memory to a disk cache has diminishing returns to scale, thus Carolyn's solution would peak at less than optimal efficiency. |
|
|
Problem 5-21 |
|
|
What is the difference between a virus and a worm? How do they each
reproduce? The biological counterparts to these virtual nasties are a good analogy. A virus in the real world is not a complete organism but an entity whose genomes are elements of nucleic acid that replicate inside living cells to cause the synthesis of virons that can transfer the genome to other cells. Similarly, a computer virus is not a complete program and cannot run on its own. It must first infect a file before it can replicate. Once infected, this file must be accessed (activating the virus) before it can cause the spread of the virus to other files. The virus then seeks uninfected files to pass a copy of itself on to. These will typically spread between shared computers, mounted drives or shared removeable disks. The main limitation of a virus is that it must have direct access to a file before it can spread. Worms on the other hand are complete organisms which can survive on their own. Computerized worms are by themselves, complete programs. They are created with the purpose of executing a specific task. The original harmful worm was created by Robert Morris, a 23 year old student at Cornell. In 1988, he released this very buggy program on the internet which tried to log on to remote systems whose addresses were stored in the host table and hack in using common passwords. Once the worm had infected the system, bugs in the program caused it to replicate itself violently, overloading systems and eventually crashing over 6,000 machines world-wide. |
|
s-hillbrand@uchicago.edu