On Fri, 14 Jan 2000, Martin Buchholz wrote:
> AV> Ah, I see. We should allow user to configure the page size on x86. Would
> AV> you care to explain how to do that? Unfortunately
> AV> #define PAGE_SIZE 696969 /* hardware limits? wassat? */
> AV> will not exactly do the thing you want. What part of "stack is finite" is
> AV> hard to understand? It's not EMACS, ferchrissake. Limit is imposed by
> AV> recursion. Changing it without the corresponding change of recursion
> AV> footprint is not going to do you any good, all unholy GNU creed ("thou
> AV> shalt not have limits, common sense included") nonwithstanding.
>
> `Common sense' suggests that:
>
> - the symlink-chasing algorithm can be implemented with fixed stack
> space.
Taking care of all races. Taking care of the case when some symlinks are
not really symlinks (procfs). Not harming the common case (== sane setup).
Well, go ahead, show how to do it.
> - If the kernel has some kind of weird problem that it can't run
> arbitrary C code, then the symlink-chasing should be delegated to
Oh, yes. And it can't sleep in bottom halves. And it doesn't have embedded
elisp interpreter. So?
> libc, and open() and friends can be libc functions that only pass
> resolved symlinks to the system call. libc already does
Races. Quite a few may be exploitable.
> symlink-chasing, for example in realpath(). It's certainly common
> sense for functions like open() and realpath() to work
> _consistently_. For them to have different symlink-chasing limits
> is insane. But is there a way for libc to actually know what the
> kernel limit is, so that it can be consistent?
Consistent? You do realize that realpath() not returning -ELOOP does not
guarantee that you will not get -ELOOP on subsequent call of open(), don't
you? On _any_ OS. If you don't see why - too bad, I just hope that you
never wrote anything security-related.
> AV> How about RTFS before getting shocked? It would spare you the shock, BTW -
> AV> symlink patch drove the footprint down to ~100 bytes/recursion level and
> AV> that allowed to raise the limit. If you need more than 32 _nested_ (and
> AV> that's the only thing that ever was limited) symlinks - too bad.
>
> Is it really impossible to implement symlink chasing in fixed stack
> space? You guys are clever - surely this is not beyond your abilities.
Wait a minute. Do you mean that you want _more_ than 32 nested symlinks?
> AV> ObYourProposal: feel free to submit patches. Keep in mind that code
> AV> quality requirements tend to be slightly stricter than in EMACS - eight
> AV> megabytes and constantly swapping is Bad Thing(tm). If you need bloat you
> AV> know where to find it.
>
> Insulting other free software projects is not productive, especially
> when the only connection to the current conversation is my email address.
No, it isn't. Let me explain what I mean: most of GNU code in general and
EMACS derivatives in particular badly suffer from the "who cares for
real-life cases" braindamage. I.e. the code is bloated beyond belief for
no good reason.
And IMNSHO whining about said limit without as much as RTFS or figuring
out the basics of kernel architecture is lossage. Very closely related to
the aforementioned, erm, style.
I'm not trying to insult "other projects" (and frankly, I don't really
care), but IMO the coding style and quality of 90% GNU code I've seen is
intolerable for the kernel. It's bad enough in userland, but there it
doesn't inflict lossage on users who do not run it. In the kernel it
affects everybody.
> When I discovered the 5-symlink limit, my estimate of the kernel
> quality dropped greatly. The kernel (or at least the kernel/libc
> combination) is there to provide reliable services to userland.
... at decent speed assuming that userland requests are reasonable.
-
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 : Sat Jan 15 2000 - 21:00:26 EST