lkml.org 
[lkml]   [1996]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Eliminating symlink recursion
From
Date
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>


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.057 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site