Both of the OSes handle this problem in the same way, though it is
implemented slightly differently. Both use the same system for
multiple programs that run concurrently, whether under one user or
multiple users.
Basically, programs declare that they want to use a file by a process
known as locking the file; there are two forms of locking a file, read
and write, and both can be done in either exclusive or shared mode.
Their declaration is put in the file descriptor, which is where
information about the file is stored and accessed.
Generally it is preferred to use the shared mode of locking, called
'advisory locking' under *nix systems, versus the exclusive form of
locking, termed 'mandatory locking' in *nix.
These modes are just as they sound; shared or advisory locking merely
indicates that the file is in use and involved in some program or
another; shared locks increment a counter in the file descriptor, and
leave it up to the next program trying to establish a lock to the file
to process this information if it chooses (for instance, by waiting
until all other programs have finished working with the file, or by
declaring another shared lock on the file).
Exclusive/Mandatory locking requires that no other programs access the
file during the time the lock is established; it is generally
unnecessary for files like documents, but it could be a vitally
important distinction, for system libraries in Windows for example. If
a write lock is established in this mode, no other program may write
to it; if a read lock is established this way, no other programs may
read from the file concurrently. When this happens, other processes
may stop and wait, checking every once in a while, when they see the
mandatory lock flag is set; or they can just give up on the file and
return some sort of an error or message to the user.
As a side note, Windows locking does not check properly for file
permissions before attempting to lock a file, only when actually
reading/writing data to the file. This presents a security risk, as a
malignent program could conceivably block access to all files on the
disk by locking them exclusively.
See the last link below for details.
As another aside, there is an alternative form of locking available
under Windows, described in detail in the second link.
From:
http://www.ecst.csuchico.edu/~beej/guide/ipc/flock.html
"There are two types of locking mechanisms: mandatory and advisory.
Mandatory systems will actually prevent read()s and write()s to file.
Several Unix systems support them. Nevertheless, I'm going to ignore
them throughout this document, preferring instead to talk solely about
advisory locks. With an advisory lock system, processes can still read
and write from a file while it's locked. Useless? Not quite, since
there is a way for a process to check for the existence of a lock
before a read or write. See, it's a kind of cooperative locking
system. This is easily sufficient for almost all cases where file
locking is necessary."
From:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q129202
"With Exclusive Oplock, if a file is opened in a non-exclusive (deny
none) mode, the redirector requests an opportunistic lock of the
entire file. As long as no other process has the file open, the server
will grant this oplock, giving the redirector exclusive access to the
specified file. This will allow the redirector to perform read-ahead,
write-behind, and lock caching, as long as no other process tries to
open the file.
When a second process attempts to open the file, the original owner
will be asked to Break Oplock or Break to Level II Oplock. At that
point, the redirector must invalidate cached data, flush writes and
locks, and release the oplock, or close the file.
Opportunistic Locking level II, provides a method for granting read
access to a file by more than one workstation, and these workstations
can cache read data locally (read-ahead). As long as no station writes
to the file, multiple stations can have the file open with level II
oplock."
From:
http://www.securiteam.com/windowsntfocus/6J00H0U3GW.html
"Applications can lock the file after file descriptor is open by
application (or in the open() call itself). Usually there are two
modes for locking - SHARED and EXCLUSIVE. A single application can put
the EXCLUSIVE lock on a file. If file is locked exclusively, no
further locks can be put on the file by any another process. The main
problem of the file locking mechanism is that it does not check for
any file permissions or the mode the file is opened with before
locking is done. This makes it possible for an application with
read-only (Under privileged) access to a file to lock it exclusively.
The way file locks interfere with file access depends on the
particular OS. There are two possible situations: moderate and
non-moderate file locks. *BSD and Linux use non-moderate locking,
while Windows NT locking is moderate. What does it mean? Under UNIX,
file locking is only checked when another application tries to lock
the file. If the application does not use file locking, it will not be
affected by file locking. Under Windows, things are different. If one
application exclusively locks the file, another application cannot
access this file even if it does not try to lock the file. This should
be treated as a design flaw, because the mechanism for file locking
needs to interact security mechanism and verify the application's
files permissions.
This means that many security critical mechanisms under Windows can be
DoS'ed by file locking."
Finally, here's how it's handled with Python under Windows, very
similarly to the 'flock' method under Unix:
http://aspn.activestate.com/ASPN/Python/Reference/Products/ActivePython/PythonWin32Extensions/Windows_NT_Files_.2d.2d_Locking.html
Search Strategy:
://www.google.com/search?q=file+locking+windows+write+read
://www.google.com/search?q=read+lock+write+unix+file
Hope this was helpful. Please ask for clarification if necessary.
- bookface |
Clarification of Answer by
bookface-ga
on
21 May 2002 04:05 PDT
You asked how this applies to a distributed environment; the answer is
that the files are accessed the same way, no matter how they are
called for, by multiple users or one user. *nix systems are focused on
the multiuser aspect more so than Windows machines, but again in both
cases (Windows NT following the lead of the first-gen *nix machines,
as it does in many aspects of its networking protocols) they are
accessing the file the same way. Wherever the file is being stored,
locally or remotely, there is a file descriptor that contains
information about the file such as the size, date of creation/last
modification/last access, and more relevently, the number of locks on
the file of each type. If there is an exclusive lock, access to the
file is denied; if there is a shared lock, the counter is incremented.
There aren't going to be many diagrams of this available; I don't know
that it can really be diagrammed, even, as it is not a very
visually-oriented concept. I will try to explain it as simply as I
can, though, and present the diagrams I do find.
The OS keeps track of all the processes and cycles through each one
with the allotted amount of CPU time, while the file locks are kept
track of on the disk with the directory listing of the file.
Multi-tasking OSes cycle through all the processes giving each a
certain amount of CPU time, sometimes modified by a priority code,
which is kept with the information about the process.
Each process or program, when it is actively being processed, can
establish a lock on a file, if the file is not already exclusively
locked. If it is successful in locking the file, the counter (on the
disk, with the other information about the file) is incremented. If it
is not successful, i.e. an exclusive lock is needed or requested and
the file is being used by other processes, then either the file is
given up on and an error message is returned, or the request is just
deferred and each time the processor cycles back to the program
requesting the lock it checks again to see if the file is free.
There is only one diagram of processes accessing a file I could find,
though it is techincally for QNX, a POSIX-complient system (not quite
Unix, but generally speaking, the same concept--closer to UNIX than
Linux is):
[Two processes open the same file, one linking to it twice]
http://qdn.qnx.com/support/docs/neutrino_2.11_en/sys_arch/images/tmpfile.gif
from
http://qdn.qnx.com/support/docs/neutrino_2.11_en/sys_arch/proc.html
NOTE: I should point out for this diagram a simplification I was
trying to make; the processes keep copies of the file descriptor
themselves, which is what this diagram shows. You can ignore this for
your purposes--all that is important is that the file is being
accessed.
A real-world example regarding the use of Perl on databases, as well
as a simple text diagram, can be found at:
http://stason.org/talks/apachecon2000/OR093/html/dbm.html#Locking_dbm_handlers
though the content is fairly clear, the diagram is not very well
explained. P1 is trying to access the file to write to it, which
requires a lock to the file that cannot be processed until no other
programs are using it; p2, p3, p4, and p5 are making requests to the
file at varying durations and at varying times, but p1 is blocked from
access, because it cannot do its work simultaneous to the other
processes.
Since this system is not very effective if writes need to be
preformed, the solution is a new implementation of the locking
procedures, wherein programs that need to read a file regularly over a
long duration do NOT keep open locks to files, but rather poll them
and have a seperate database to keep track of changes. Effectively the
data is transferred the same way, but the files are kept free for use
with much shorter lock times, the cost of this being an increase in
processing power and memory required.
It should be noted that this example is NOT involving any new forms of
locking; rather, it shows how the forms of locking given above can be
cleverly manipulated to produce whatever results are desired.
Another diagram:
http://joda.cis.temple.edu/~ingargio/old/cis307f95/readings/unix2.html
Additionally, I thought this restatement of the above in terms of
programming in C (though the description in the first few paragraphs
is non-language specific) might be useful:
http://www.cs.uleth.ca/~holzmann/C/system/lockfile.html
A diagram showing the possible process states in QNX--the diagram
includes various states that the program might enter while waiting for
data:
http://www.qnx.com/literature/qnx_sysarch/proc.html#PROCESSSTATES
(if down, use
http://216.239.33.100/search?q=cache:rs45uVtHEh4C:www.qnx.com/literature/qnx_sysarch/proc.html#PROCESSSTATES
)
A set of slides (text) from a class on distributed file systems:
Relevant information about processes, though no information about file
locks:
http://tangle.seas.gwu.edu/~shmuel/cs251/procthread.pdf
Other slides:
http://www.seas.gwu.edu/~shmuel/cs251/cs251.html
Also, I thought you might be interested in this PDF file, where
BlueArc explains its Si7500 Storage System, which allows native access
from Windows and UNIX clients to the same files, and explains why this
is a security issue: the interaction between the two systems is often
grafted on, and the file locking modes are mapped out onto each other
without replicating functionality exactly.
http://www.bluearc.com/html/news/downloads/datasheets/security_wp.pdf
Hope this clears things up.
|
,
0 Comments
)
