+------------------------------------------------------------------+ | Linux Security: Tips, Tricks, and Hackery | | Published by Onsight, Inc. | | | | 23-June-2003 | | http://www.hackinglinuxexposed.com/articles/20030623.html | +------------------------------------------------------------------+ This issue sponsored by EFF: Defending Freedom in the Digital World The Electronic Frontier Foundation (EFF) is a membeship organization that needs your help. EFF works to protect civil liberties taht relate to new technologies. Our lawyers engage in cases that champion online freedoms, our site archive is a comprehensive digital rights resource, and we've developed a powerful media presence. Check out http://www.eff.org/ to learn more. -------------------------------------------------------------------- Linux file locking mechanisms - Mandatory Locking By Brian Hatch Summary: Mandatory Locking can enforce file locks at the kernel level. Last week I described three locking functions - flock, lockf, and fcntl. These functions, while managed by the Linux kernel, are known as advisory locking mechanisms. Any program which doesn't bother checking to see if a lock is in place will never know. The kernel won't stop it from reading or writing the file. This can be a problem when some programs correctly wait for an exclusive lock on a file, but other programs out of your control access the same files simultaneously without lock checks. If you don't have the code, it may be difficult or impossible to wrap some sort of external locking mechanism around the closed source program. In these cases, you can enforce locking at the kernel level with mandatory locks. Mandatory locking is implemented on a file-by-file basis. When a program attempts to lock a file with lockf or fcntl that has mandatory locking set, the kernel will prevent all other programs from accessing the file.[1] Processes which use flock will not trigger a mandatory lock. To enable mandatory locking, you must first mount the filesystem with the mand mount option: # mount | grep /data /dev/hda7 on /data type ext3 (rw,noatime) # mount -oremount,mand /boot # mount | grep /data /dev/hda7 on /data type ext3 (rw,mand,noatime) Here I remounted the /data directory with the mand option. (I should add mand to the appropriate /etc/fstab entry to have this setting survive reboots as well.) To prevent mandatory locking from taking over the entire filesystem, only specifically tagged files will exhibit mandatory locks. The way you define a file to be governed by mandatory locks is to set the sgid (setgroupid) bit, but not the group execute bit. This combination doesn't make any sense normally,[2] which is why it was chosen for this purpose. So, say we needed to enforce mandatory locking on the files d_* in a directory, we'd do the following: $ cd /data $ ls -l -rw-r--r-- 1 dbrand stuff 82756 May 28 14:07 a_5772.dat -rw-r--r-- 1 dbrand stuff 7788 May 28 14:07 a_9298.dat -rw-r--r-- 1 dbrand stuff 3325 May 28 14:07 d_0283.dat -rw-r--r-- 1 dbrand stuff 19288 May 28 14:07 d_5755.dat -rw-r--r-- 1 dbrand stuff 1224 May 28 14:07 d_5758.dat $ chmod g+s,g-x d* $ ls -l -rw-r--r-- 1 dbrand stuff 82756 May 28 14:07 a_5772.dat -rw-r--r-- 1 dbrand stuff 7788 May 28 14:07 a_9298.dat -rw-r-Sr-- 1 dbrand stuff 3325 May 28 14:07 d_0283.dat -rw-r-Sr-- 1 dbrand stuff 19288 May 28 14:07 d_5755.dat -rw-r-Sr-- 1 dbrand stuff 1224 May 28 14:07 d_5758.dat Henceforth, the d_* files will exhibit mandatory locking. The capital "S" in the output signifies that the sgid bit is set, but there is no underlying execute ("x") bit, which is what we need. Mandatory locks should only be used where you have problem software you cannot modify to use locks correctly. Even with mandatory locks, you can still have conflicts. If program A reads in a file, program B locks, edits, and unlocks the file, and program A then writes out what it originally read, you're still in a pickle. However in many cases, mandatory locking can help prevent corruption of your data. The other potential problem with mandatory locks is that nothing, not even root-owned processes, can override the lock. The best root could do would be to kill the process that has the lock on the file. This could be particularly nasty if the mandatory-locked file is available via NFS or other remotely-accessible filesystem, as the entire fileserver process itself will block until the lock is released. NOTES: [1] To be exact, if a program has a read or shared lock on a file, no other program can write to it. If a program has a write or exclusive lock on a file, no other programs can read or write to it. [2] The sgid bit is put on programs that should run with different group permissions than the invoking user. When a program doesn't have the group execute bit set, this situation is rather meaningless ------------- 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 as 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 24 2003 - 01:28:00 PDT