Linux file locking mechanisms - Flock, Lockf, and Fcntl

[InfoSec News <isn () c4i org>]

+------------------------------------------------------------------+
|  Linux Security: Tips, Tricks, and Hackery                       |
|  Published by Onsight, Inc.                                      |
|                                                                  |
|  16-June-2003                                                    |
|  http://www.hackinglinuxexposed.com/articles/20030616.html       |
+------------------------------------------------------------------+

This issue sponsored by Onsight, Inc, your source for open-source
solutions.

Onsight offers on-site training on Basic Perl programming, Advanced
Perl programming, CGI programming using Perl, Tcl/Tk, XML and
JavaScript. All courses are hands-on, designed by real-world
consultants and fully customizable. Because all classes are on-site,
our overhead is low and our prices consistently beat those of our
competitors. Every Onsight instructor is a seasoned consultant able
to provide back-end web programming, network security, system
administration and other support services.

For more information, visit http://www.onsight.com

--------------------------------------------------------------------

Linux file locking mechanisms - Flock, Lockf, and Fcntl
By Brian Hatch

Summary: Multitasking operating systems can be prone to race
conditions, but implementing proper file locking routines can prevent
programming mistakes.

Ever had two processes attempt to access the same file at the same
time? Unlike some older PC operating systems, Linux doesn't prevent
this in any way. The Unix philosophy is to grant access to a file
(assuming file permissions permit it) to an unlimited number of
process.

This can easily lead to nasty problems. Say you had two mail clients
running at the same time, and both tried to rewrite /var/mail/USER at
the same time that your mail delivery agent[1] tried to add some new
emails to the end. If they weren't programmed to play friendly, the
result could be a horribly corrupted mail spool and loss of email
messages.[2]

As you can guess, file locking can be very important in
security-critical code as well. The last thing you'd want to happen
is for one process to be logging to a file and have a second version
wipe it out, or a program that stores temporary authentication tokens
erase entries used by a separate process, or have two programs that
add users to /etc/passwd write at the same time, resulting in
corrupted or passwordless accounts.

If you're programming in C, there are several locking functions
available to you.

flock(fd, operation)
    Locks or unlocks an entire file. Doesn't work on NFS mounted
    filesystems, unfortunately. Available operations are
   
    LOCK_SH Create a shared lock                                     
    LOCK_EX Create an exclusive lock                                 
    LOCK_UN Release our lock                                         
    LOCK_NB Don't block when setting the lock. Return an error if the
            action cannot be completed.                              
   
lockf(fd, operation, offset)
    Locks or unlocks the portion of the file after offset. Allows you
    to lock just trailing portions of the file, if desired. lockf is
    just a front end for fcntl. Arguments:
   
    F_LOCK  Create an exclusive lock                                 
    F_TLOCK Create an exclusive lock or return an error immediately  
    F_ULOCK Release our lock                                         
    F_TEST  Test if the file is locked by another process.[3]        
   
fcntl(fd, command, struct flock );
    fcntl offers you the most locking control. The flock structure
    details the beginning and end of the segment to lock. It has
    arguments analogous to those for lockf and can differentiate
    between read and write locks. (fcntl can do other things too,
    such as setting the close on exec flag, duplicating a file
    descriptor, and more.)

Most languages have similar functions. For example Perl uses the
flock function, which may use flock, lockf, or fcntl under the hood.

Now naturally, the most important thing about these locking
mechanisms is that any application that could be accessing the files
in question must also use the same locking mechanism.[4] And this is
unfortunately a problem when you don't control all the software in
question. Next week I'll cover mandatory locking, which can provide
guarenteed locks even when not all processes cooperate.

NOTES:

[1] For example mail.local, procmail, etc

[2] The maildir mailbox format was created for just this reason. A
maildir mailbox is simply a set of directories, with each email
message stored in a separate file. This setup allows simultaneous
access to the mailbox without requiring any locking functions
whatsoever, functioning even on remotely mounted filesystems.

[3] Of course, this is a potential race condition, because between
the test and any action you take, another process may lock the file.

[4] I.E. flock vs {lockf,fcntl}.

                            -------------                            
Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
Linux Exposed and Building Linux VPNs. He likes to periodically
delete /etc/passwd and /etc/shadow and reboot to enforce the ultimate
Linux locking system. Brian can be reached at
brian () hackinglinuxexposed com.

--------------------------------------------------------------------
This newsletter is distributed by Onsight, Inc.

The list is managed with MailMan (http://www.list.org). You can
subscribe, unsubscribe, or change your password by visiting
http://lists.onsight.com/ or by sending email to
linux_security-request () lists onsight com.

Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/

--------------------------------------------------------------------

Copyright 2003, Brian Hatch.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.