wrowe at rowe-clan
Jul 20, 2006, 11:02 AM
Post #5 of 8
(1424 views)
Permalink
|
|
Re: svn commit: r423886 - in /httpd/httpd/trunk: CHANGES server/request.c
[In reply to]
|
|
Joe Orton wrote:
>
> I think it's a *very* bad idea to imply that SymLinksIfOwnerMatch is a
> security feature.
>
> If you did want to call this a "security feature" then you also need to
> fix the big fat race condition inbetween all those nice careful stat()
> calls and the default handler going to open the file. Which I doubt
> would be simple to say the least.
>
> I'd stay well clear of the word "security" here.
+1. I simply don't see how we can permanently solve every case where users
are permitted to modify the server. And in fact; I'd like us to finally
divorce all of the "foolish/nefarious web author has done X to administrator's
server", into their own class of bugs. Let's give this a name other than
'security vulnerability'.
There are a bazillion other things nefarious users, who an administrator has
put faith in, can do to a server. Let's try to narrow this down to "Untrusted
User" and "Untrusted Author" categories (1. has a shell for various operations
to perms, symlinks, run scripts, etc etc), 2. can only place 'files' into the
web space).
The "security" rule of apache is simple, anything user "nobody" can see, apache
is capable of serving, and it's up to the administrator to configure such that
1. user "nobody" has no access to the files, or
2. configure apache in such as was as to "avoid" serving those files.
|
