+------------------------------------------------------------------+ | 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 brianat_private -------------------------------------------------------------------- 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-requestat_private 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 majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Tue Jun 17 2003 - 03:29:26 PDT