The following reply was made to PR general/1402; it has been noted by GNATS.
From: [EMAIL PROTECTED]
To: Dean Gaudet <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: general/1402: Relative Symlinks are handled improperly
Date: 14 Nov 1997 07:58:23 -0000
Dean Gaudet wrote:
>
> [What, is this the week where everyone who submits bugs has to do so in a
> derogatory manner? It's sure nice to feel appreciated. Not. I apologize
> in advance if your message was jovial and I didn't catch the joke.]
I was really tired and really cranky. My hand was hurting. You're right.
I hate bug reports like that too. Especially they're misinterpretations of
the problem.
As some penance, I got your address from internic and just wrote you a
personal check. Expect it next week. Sorry again...what else can I say?
And thank you.
> I cannot reproduct this bug:
>
...
> > Symlinks should be expanded in the filesystem pathname and not the URL.
>
> As I said earlier, they're never expanded. We'd have to use readlink()
> to do that, I challenge you to find a call to readlink() in Apache.
I screwed up and misinterpreted my logs. But you already knew that
something like that must've happened.
For what its worth, my Alias directive was in a VirtualHost directive and
some of my testing was done by telnetting to localhost:80 and getting a raw
path. Thus missing the VirtualHost directive and the Alias. It looked like
the symlink was screwy. I was really tired...and even more tired of trying
to figure out why FollowSymLinks wasn't working.
I have some related weirdness which I'll include in another reply.
> > PS: I concur with bug 922. Symlinks owned by root should always be
> > respected, regardless of SymLinksIfOwnerMatch.
>
> That's a nice opinion. Are you aware that there are systems, which are
> POSIX compliant, on which the owner of a symlink is absolutely irrelevant?
> For example, on said systems, to create a symlink with a particular owner
> you must setuid(owner) first. On said systems, if a user directory is
> restored from backup, or copied from one filesystem to another, then
> all symlinks in that user's directory will be owned by root.
>
> We have no desire to figure out which systems behave like that.
> So SymLinksIfOwnerMatch won't be changing to cater to the systems which
> do allow chown()ing of symlinks.
On these systems with the screwy symlink ownership, SymLinksIfOwnerMatch is
broken already and therefore worthless, right?
On systems where it works, it seems that root is trustworthy.
Food for thought. Your call.
> > To continue on a related nit...
> > It disturbs me that apache does not provide chmod-like behavior wrt
> > symlinks.
> > The expanded name should then be checked against Directory directives to
> > determine if
> > access is permitted.
>
> If you want this to change then submit a feature request. As documented
> Apache does not do this. Symlinks are never expanded. If you want a
> personal opinion, I'll give you mine: relying on symlink protection in
> Apache is a bad idea. The only real solution is a chroot() cage.
You're right. That's better.
Stig
