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: Florian Diesch on 25 Feb 2010 12:20 Rahul <nospam(a)nospam.invalid> writes: > Florian Diesch <diesch(a)spamfence.net> wrote in news:712957-cmg.ln1 > @mid.florian-diesch.de: > >> That's often done because creating symlinks is an atomic action (in >> contrast to writing the data into a file). >> > > What about just "touching" a file. Isn't that an equally atomic operation? Yes, but it can't store additional data. Often it's useful to store e.g. the PID of the process that created the lock file to be able to check whether that process is still running. Florian -- <http://www.florian-diesch.de/grundgesetz.html>
From: unruh on 25 Feb 2010 14:33 On 2010-02-25, despen(a)verizon.net <despen(a)verizon.net> wrote: > 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. Of course there is a delay between checking and using the file. Computers are not instantaneous. The programming code required to open the file takes a finite time to actually be performed (the machine code instructions each take a finite time to execute). He is saying that if there is a long enough chain of sym links, the operating system file system code has to open each sym link, read it, open the next in the chain read it, etc. That process takes a while. By the time it gets to the end of that chain, the file that used to be there could have been changed. This has absolutely nothing to do with the script. This is all at the kernel/filesystem level.
From: despen on 25 Feb 2010 19:25
unruh <unruh(a)wormhole.physics.ubc.ca> writes: > On 2010-02-25, despen(a)verizon.net <despen(a)verizon.net> wrote: >> 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. > > Of course there is a delay between checking and using the file. > Computers are not instantaneous. The programming code required to open > the file takes a finite time to actually be performed (the machine code > instructions each take a finite time to execute). He is saying that if > there is a long enough chain of sym links, the operating system file > system code has to open each sym link, read it, open the next in the > chain read it, etc. That process takes a while. By the time it gets to > the end of that chain, the file that used to be there could have been > changed. This has absolutely nothing to do with the script. This is all > at the kernel/filesystem level. If I really, really needed to insure I had the right file, I think I'd open it first, then check it's characteristics. Doing the stat before the open opens a hole. Whether its a big one or small one seems like a minor issue. |