The following reply was made to PR general/1402; it has been noted by GNATS.
From: Dean Gaudet <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: general/1402: Relative Symlinks are handled improperly Date: Fri, 14 Nov 1997 00:29:59 -0800 (PST) On 14 Nov 1997 [EMAIL PROTECTED] wrote: > 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. No problem, I apologize too for the curtness of my reply. > 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. That's not necessary I assure you! > > > 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? SymLinksIfOwnerMatch works until you copy a users directory as described ... but a malicious user could have done "ln -s / hahaha" and it would become a hole after a restore or home directory movement. So if we treat root specially we open this subtle attack. > > 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. I'm working on another security model for Apache ... I'm trying to figure out another solution to this problem. But I'm too busy lately to get anywhere on the work. chroot() should be easier in the model; including chroot() compartments for CGI users. I'll announce it when I've got something to show. Dean
