hard links to files on other filesystems disallowed: why?
in [General Linux]
|
Prev: how does user application call NAPI poll method of network device driver.
Next: firefox and google maps
From: John Hasler on 24 Feb 2010 17:06 I wrote: > Obviously this only works for the simplest sort of lockfile but it has > been used successfully for decades. Florian writes: > It usually doesn't help if data is stored in the file name as in that > case the new file name is most likely different from the old one and > you often don't even know the old file name and have to search for a > possible existing old lock file first before calling open(). It works fine when the file name is something such as "ttyS0.LCK". Of course, the only information this conveys is that ttyS0 is locked, but sometimes that is all you needs to know. If you need more don't use this method (or accept the speed penalty and race-condition risk resulting from putting data in the file). -- John Hasler jhasler(a)newsguy.com Dancing Horse Hill Elmwood, WI USA
From: Maxwell Lol on 24 Feb 2010 21:08 > The *filesystem* assumes that a dangling hard link is an error, > applications really have no input to the matter. Rahul, Here is what you have to undestand. 1) Directories are files. Directories do not "contain" the data inside files. They merely point to the starting location, the inode. They also contain the name (relative to the directory). The directory file is found by reading the data inside the inode corresponding to a directory. 2) Creating a hard link does NOT copy the file data. It just changes the contents in a directory, so that there is another entry (the filename) and the inode (which indicates where the data starts on the disk). If you want a file to be duplicated onto a different file system it MUST be copied. Here's some more for you to digest. Think of a directory, such as "/" On my system it's in the inode 2. The directory "/" is just a file (inode #2). it's a special file that only the OS can change. If we allowed the user to change the data in the directory, it could become corrupted. In older versions of UNIX, one could do a simple "od < ." and it would dump the data inside the directory file. (Now I get a read error). So the directory "/" is stored in inode 2. Sample data inside a directory file. Filename inode .. 2 ... 2 bin 40721 boot 40722 etc 24334 proc 1 sys 1 If I want to see /etc, in inode 24334, I will see something like .. 24334 ... 2 acpi 73299 etc., etc. Note that /etc/. is the same inode as /etc, and that /etc/.. is the same inode as /, /., and /.. A symbolic link points to a filename. If the OS goes to the filename by reading the contents of each directory inthe path, to find the inode for the next file/directory in the path, it will get to a new inode - which may be on a different file system. A symbolic link never promises to point to a valid file. One more point. The inode does not contain the actual data. It is a special block that contains pointers to the actual blocks of data on the disk. So you can change blocks of data in an inode if you wish, without chaning the indoe number. Files can grow in size, and shrink. There's more to this, as filesystems have blocks and block fragments, keep track of used and unused blocks. There are also cylinder groups, which are blocks that are physically nearby. It's complicated.
From: Maxwell Lol on 24 Feb 2010 21:20 J G Miller <miller(a)yoyo.ORG> writes: > On Sat, 20 Feb 2010 22:15:25 -0500, despen wrote: > >> There is no requirement that the target of a soft link exist. > > Indeed not, but it does raise the issue of whether or not > dangling links are dangerous and a potential security hole. Danging symlinks are indeed a problem. There are attacks where one can create a symlink to a symlink to a symlink, etc. If the links form a chain that is long enough, an attacker can let the OS check the permissions of the final target, and then plan to do something privledge with that target. But in the meantime the attacker can change the symlinks to point to a new file. It's a race condition, and with links that are very long, the attacker can win the race. Example: Linux cannot have setuid shell scripts because of this race condition. Solaris solves the problem by opening the script, and connect it to a file descriptor, and THEN making a setuid to root shell process, passing it the open file descriptor. (and not the file name). This eliminates the race condition.
From: Maxwell Lol on 24 Feb 2010 21:24 Rahul <nospam(a)nospam.invalid> writes: > What about just "touching" a file. Isn't that an equally atomic operation? It cannto be used to eliminate the race between two processes. Creating a lock file will either succeed (and means the owner owns the file), or it fails.
From: despen on 25 Feb 2010 10:49
Maxwell Lol <nospam(a)com.invalid> writes: > J G Miller <miller(a)yoyo.ORG> writes: > >> On Sat, 20 Feb 2010 22:15:25 -0500, despen wrote: >> >>> There is no requirement that the target of a soft link exist. >> >> Indeed not, but it does raise the issue of whether or not >> dangling links are dangerous and a potential security hole. > > Danging symlinks are indeed a problem. There are attacks > where one can create a symlink to a symlink to a symlink, etc. > > If the links form a chain that is long enough, an attacker can let the > OS check the permissions of the final target, and then plan to do > something privledge with that target. But in the meantime the attacker > can change the symlinks to point to a new file. It's a race condition, > and with links that are very long, the attacker can win the race. > > Example: Linux cannot have setuid shell scripts because of this race condition. > > Solaris solves the problem by opening the script, and connect it to a > file descriptor, and THEN making a setuid to root shell process, > passing it the open file descriptor. (and not the file name). > This eliminates the race condition. I don't see how you just described a problem with dangling sym links. There aren't any dangling sym links in your description. Besides that, the problem seems to be a logic problem in the script. If there is a delay between checking the file and using the file then the check is faulty. |