Messages in this thread |  | | Subject | Re: Eliminating symlink recursion | From | John Sullivan <> | Date | Wed, 5 Jun 1996 03:42:36 +0100 |
| |
In article <Pine.A32.3.93.960603145330.61364B-100000@gpu2.srv.ualberta.ca> you write: >All Linux kernels so far resolve symbolic links recursively. To prevent >kernel stack page overflows, most file systems limit the recursion level >to 5. This limit also means that the kernel does not need to deal with >symbolic link loops because these will eventually exceed the limit.
Which is, technically, one way of dealing with symlink loops?
>This new follow_link uses a stack-like data structure to keep track of >symlink inodes it visits and partial pathnames that still need to be >resolved. This
allows a user process to initiate an action which may cause unbounded consumption of kernel resources (whether or no it eventually fails and gives up, if the sysadmin sets my hard memory limit to 16K, I should not be allowed to be perverse enough to create a chain of symlinks large enough to cause the VFS to eat all of the machines ram. /tmp/1->2->3->...->16000000->adirectory, then 'cd 1' anyone?
Maybe other parts of the system behave vaguely like this, but the current situation is fairly neat, and doesn't break anything AFAIAA.
>data structure resides in kernel data space and grows and shrinks >(in PAGE_SIZE chunks) as required. Thus the new limit depends on >the amount of kernel data space remaining at any particular point >in time.
So you could be perverse enough to create a structure that eats very large amounts in the kernel data space?
Also, the resulting filesystem has undefined behaviour, even for relatively sane cases. Eg:
~$ cd spong cd: Memory Exhausted ~$ cd spong cd: Memory Exhausted ~$ cd spong cd: Memory Exhausted ~$ cd spong spong$ ~$ cd ../spong cd: Memory Exhausted
Glerk???
In the current implementation, accessing a symlink will always succeed or fail predictably for a given symlink structure, which is probably a good thing.
>My remaining concerns with this change are: > > - follow_link is a fairly central part of VFS, and thus any change to > it needs thorough testing.
Probably, but in most parts of the kernel 'Here be Dragons'.
> - There is some question in my mind as to what priority should be used > in allocating the pages used for the stack. For now, I use > GFP_KERNEL.
Sounds right, unless the VFS could be called from dodgy places in which case GFP_ATOMIC may be more appropriate? Or you may want to try caching previously resolved symlinks... ;)
John -- i built it up now i take it apart climbed up real high now fall down real far no need for me to stay the last thing left i just threw it away i put my faith in god and my trust in you now there's nothing more fucked up i could do <p><a href="http://callisto.girton.cam.ac.uk/users/js10039/">Me.</a>
|  |