On Fri, 14 Jan 2000, Martin Buchholz wrote:
> Basically, symlink-chasing is directed graph walking. You're looking
> for a leaf node. Each step in the graph walk has to deal with all of
> your security and procfs issues. The question of loop detection
> should be separate and can be solved using a standard algorithm which
> uses fixed space. tortoise-hare and tarjan, I think, are two
> different names for the same algorithm.
Oh, yes. And both assume that graph doesn't change under them. Which is
patently false in case of filesystem. You have a single-threaded code -
good for you, but VFS is _not_ single-threaded. And locking everybody out
of VFS for the time of symlink lookup is not an option. One of the reasons
being that symlink lookup may trigger automounter. Which will need to
access VFS.
> I'm not going to try to figure out what races are possible, but it
> would be quite sad if userland couldn't do secure symlink-chasing at
> all. Having it done by the kernel should simply be an optimization.
Sorry, but realpath() _is_ dangerous unless you control every step of the
chain and are sure that nothing will change. That is, if you base
behaviour on its results. I'm less than happy with the concept of this
beast, BTW - WTF _is_ path to file, in the first place? If it's just a
normalization - sorry, it doesn't work (obviously - there are files with
i_nlinks > 1).
> AV> Consistent? You do realize that realpath() not returning -ELOOP does not
> AV> guarantee that you will not get -ELOOP on subsequent call of open(), don't
> AV> you? On _any_ OS. If you don't see why - too bad, I just hope that you
> AV> never wrote anything security-related.
>
> I don't want a guarantee. Obviously something could happen between
> calls to realpath() and open(). But the symlink-chase limit should be
> the same in both calls by an application.
Why?
> AV> Wait a minute. Do you mean that you want _more_ than 32 nested symlinks?
>
> In 1992, I worked on a real-world project where hitting the 20-symlink
> limit on that system was a real problem that required re-architecting
> the build environment. You might criticise a project that did that,
> but the reality is that it worked well and accomplished its goal of
> saving disk space. Every symlink in that 20-symlink path had a reason
> for existence. Whether to use symlinks or copying often comes down to
> a standard space/time tradeoff. It's up to the _users_ to decide on a
> reasonable tradeoff, and performance should gracefully decline as the
> symlink count increases.
<gaaack> Let me guess: you had the structure changing. And you were not
responsible for backups, right? Anyway, you have 32. And if somebody wants
more I'm more than comfortable with telling lusers where they can shove
their requests. Done that. More than once.
> AV> No, it isn't. Let me explain what I mean: most of GNU code in general and
> AV> EMACS derivatives in particular badly suffer from the "who cares for
> AV> real-life cases" braindamage. I.e. the code is bloated beyond belief for
> AV> no good reason.
>
> Just like the Linux kernel, Emacs is an application platform. Is
> Linux bloated beyond belief for no reason, just because you can get
> distributions that don't fit onto one CD? Have you noticed that the
> Linux kernel has been growing in size much faster than any Emacs out
> there?
You know, distributions pick a lot of junk and it's not the kernel fault.
As for the kernel growth... I think that during this Autumn I did about
-3Kloc, maybe more. Quite a bit was in symlinks patch, BTW. Notice that
volume and bloat are different things - if you will look at the sizes of
different parts you'll see that kernel proper is not growing like hell.
Now, drivers... Anyway, thanks $DEITY, the thing is not even close to
EMACS in featuritis.
> I believe if you implement the fixed space tortoise-hare
> symlink-chasing algorithm, the Linux kernel will be faster and use
> less stack space for short symlink chains as well. When I introduced
> tortoise/hare algorithms into XEmacs, the modified functions all
> got faster, despite having introduced reliable loop detection.
See above. You have a single-threaded code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:12 EST