lkml.org 
[lkml]   [1996]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Eliminating symlink recursion
On Wed, 5 Jun 1996, John Sullivan wrote:

> >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?

Sure. But the current limit is enforced by every filesystem involved
instead of by VFS. More importantly, the limit is *much* too low, at
least for my purposes.

> >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?

Point taken. I'll address this concern with an updated patch shortly.

> In the current implementation, accessing a symlink will always succeed
> or fail predictably for a given symlink structure, which is probably a
> good thing.

Agreed. I'll address this also.

> > - 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... ;)

Caching would be tricky to do. Too many things can happen that would
change the inode a symlink eventually resolves to.

Marc.

+----------------------------------+-----------------------------------+
| Marc Aurele La France | work: 1-403-492-9310 |
| Computing and Network Services | fax: 1-403-492-1729 |
| 352 General Services Building | email: tsi@ualberta.ca |
| University of Alberta +-----------------------------------+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply |
| CANADA | |
+----------------------------------+-----------------------------------+



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