From: Pete Zaitcev <zaitcev@redhat.com>
To: Marc-Christian Petersen <m.c.p@wolk-project.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Symlink indirection
Date: Fri, 13 Dec 2002 11:16:17 -0500 [thread overview]
Message-ID: <200212131616.gBDGGH302861@devserv.devel.redhat.com> (raw)
In-Reply-To: <mailman.1039792562.8768.linux-kernel2news@redhat.com>
>> Is the number of allowed levels of symlink indirection (if that is the
>> right phrase; I mean symlink -> symlink -> ... -> file) dependant on the
>> kernel, or libc ? Where is it defined, and can it be changed?
>
> fs/namei.c
>
> if (current->link_count >= 5)
>
> change to a higher value.
This is vey, very misleading statement. The counter mentioned above
is there to protect stacks from overflow, but our symlink resolution
is largely non-recursive, and certainly not in case of a tail
recursion within the same directory.
Also, consider this message from Al:
----------------------------------------------------
From: Alexander Viro <aviro@redhat.com>
Date: Mon, 3 Jun 2002 13:01:16 -0400
On Mon, Jun 03, 2002 at 12:21:59PM -0400, Matt Wilson wrote:
> SUSv3:
>
> http://www.opengroup.org/onlinepubs/007904975/basedefs/limits.h.html
>
> {_POSIX_SYMLOOP_MAX} The number of symbolic links that can be
> traversed in the resolution of a pathname in the absence of a
> loop. Value: 8
... and that has nothing to said limit of 5. What we do have limited
is the number of nested symlinks. 4BSD and derived Unices limit the
total amount of symlinks traveresed in pathname resolution. Example:
if you have
/a -> b
/b/a -> b
/b/b/a -> b
/b/b/b/a -> b
/b/b/b/b/a -> b
/b/b/b/b/b/a -> b
/b/b/b/b/b/b/a -> b
/b/b/b/b/b/b/b/a -> b
/b/b/b/b/b/b/b/b/a -> b
the pathname
/a/a/a/a/a/a/a/a/a
will resolve to
/b/b/b/b/b/b/b/b/b
and there will be 9 symlink traversals done during the pathname resolution.
However, the depth (i.e. the thing we do limit) is 1 in that case. OTOH,
with
/1 -> 2/a
/2 -> 3/a
/3 -> 4/a
/4 -> 5/a
/5 -> 6/a
/6 -> 7/a
/1
will resolve to
/7/a/a/a/a/a/a
with 6 symlink traversals and depth 6. IOW, SuS limit is not an argument
for changing the Linux one - they limit different things. They are not
independent, of course, since depth of recursion can't be greater than
total amount of symlinks we had traversed, but that's a separate story.
Frankly, all cases when I had seen the nested symlink farms of that
depth would be better served by use of bindings - these are not subject
to any limits on nesting and avoid a lot of PITA inherent to symlink
farms. To put it another way, nested symlink farms grow from attempts
to work around the lack of bindings. It's not that you need to replace
all symlinks with bindings, of course - the crown of the tree is usually
OK, it's the trunk that acts as source of pain.
next prev parent reply other threads:[~2002-12-13 16:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-13 15:06 Symlink indirection Andrew Walrond
2002-12-13 15:11 ` Marc-Christian Petersen
2002-12-13 15:20 ` Andrew Walrond
2002-12-13 17:22 ` Alan Cox
2002-12-13 15:30 ` Richard B. Johnson
2002-12-13 16:17 ` James Antill
2002-12-13 16:34 ` Andrew Walrond
2002-12-13 17:24 ` James Antill
2002-12-13 16:24 ` Andrew Walrond
2002-12-13 16:26 ` Jesse Pollard
2002-12-13 15:23 ` Richard B. Johnson
2002-12-13 16:41 ` Alfred M. Szmidt
2002-12-13 16:51 ` Jeff Bailey
2002-12-13 17:15 ` Amos Waterland
2002-12-13 17:51 ` Richard B. Johnson
[not found] ` <mailman.1039792562.8768.linux-kernel2news@redhat.com>
2002-12-13 16:16 ` Pete Zaitcev [this message]
2002-12-13 16:48 ` Andrew Walrond
2002-12-13 16:55 ` Pete Zaitcev
2002-12-13 17:04 ` Andrew Walrond
2002-12-14 5:57 ` Joseph Fannin
2002-12-14 12:47 ` Andrew Walrond
2002-12-14 13:55 ` John Bradford
2002-12-14 14:00 ` Andrew Walrond
2002-12-14 16:13 ` John Bradford
2002-12-14 19:50 ` Stephen Wille Padnos
2002-12-15 0:41 ` Andrew Walrond
2002-12-23 5:58 ` Thomas Zimmerman
2002-12-13 17:32 ` James Antill
[not found] <fa.eib7vkv.1tju08k@ifi.uio.no>
[not found] ` <fa.cnblikv.qjmuqd@ifi.uio.no>
2002-12-15 7:24 ` junkio
2002-12-15 12:17 ` Andrew Walrond
2002-12-15 12:58 ` John Bradford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200212131616.gBDGGH302861@devserv.devel.redhat.com \
--to=zaitcev@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.c.p@wolk-project.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.