Deny from hostname broken in 2.0 on MacOSX 10.2
Dear list, On MacOSX 10.2 "Jaguar", hostname based access control is broken in Apache 2.0. This problem appears in the access tests of the perl-framework, where any test that tests something like 'Deny from localhost' fails. I have since determined that deny from any other hostname is broken as well. This problem goes away when Apache 2.0 is configured to disable IPv6 support. I have stepped through the code of a regular (IPv6-enabled) builda bit and it appears that what comes back from accept(2) is an IPv6 address, which apparently doesn't resolve correctly from mod_authz_host.c. Indeed, the remote address information is eventually (sa_common.c:508) passed to getnameinfo(3) which returns unsuccessfully with EAI_NONAME. I'm not very familiar with IPv6, but I know that my DNS only has IPv4 adresses. Is there no fallback where it looks up based on the IPv4 address when it can't find resolution for IPv6? Anyway. Very unfortunate that this getnameinfo call borks on resolving the IPv6 version of localhost because that's what makes the tests fail. I think, however, that this is a platform error and not Apache-specific. As for reverse resolving IPv6 addresses in general, I don't think any network I connect to on a regular basis is set up for that. I have tried this on an IPv6-enabled FreeBSD box and all tests pass. This one however has a line defining localhost as ::1 as well as one for 127.0.0.1. Maybe I should try adding that to the Jaguar box. I don't think I have tried access control from other host names on that FreeBSD box. Could anyone opine on how serious this is and whether we should (could?) disable IPv6 by default on Jaguar? Thank you for your time, S. -- Covalent Technologies [EMAIL PROTECTED] Engineering groupVoice: (415) 856 4214 303 Second Street #375 South Fax: (415) 856 4210 San Francisco CA 94107 PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03 5531 AFB1 96AF B584 0AB1 === This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message ===
httpd-2.0.43-alpha candidates available...
for testing from http://httpd.apache.org/dev/dist/ in your preferred .tar.gz, .tar.Z or -win32-src.zip format (-win32-src.zip containing the msvc makefiles.) We expect to release this image due to two minor security exposures sometime around noon PDT today, Oct 3rd. Your participation in testing this release candidate is appreciated, as always. Thanks for your ongoing subscription to current or stable testers. Bill
Re: mod_proxy support for exchange 2000
Robin P. Blanchard wrote: > In effort to build up a reverse proxy for Exchange 2000, I've determined: > > 1) using 1.3.26 or 1.3.28dev (CVS from a few minutes ago) >a. IE clients fail IIS's auth challenge >b. if those clients are sent first through squid, auth succeeds. >c. mozilla, netscape 4x, clients succeed. From the responses you have given I am not sure exactly what they represent. What I need to see to make head or tail of this is two set of headers: The first needs to show the transaction from the browser to the reverse proxy. The second needs to show the reverse proxy to the backend server. What will also be useful is to add a set of traces for mozilla so I can see what happens in the working case. Use a tool like tcpflow on the reverse proxy to get these two traces. In order to debug this, I need to be able to compare the headers sent to/from the browser with the headers sent to/from the backend server to see what has changed. Regards, Graham -- - [EMAIL PROTECTED]"There's a moon over Bourbon Street tonight..."
mod_dav behaviors
On Wed, Oct 02, 2002 at 09:28:51PM -0500, William A. Rowe, Jr. wrote: >... > Ryan and I spent literally an HOUR on the phone dissecting this issue. > I don't have the brain cycles to fully dump that conversation back, but it > comes down to this; > > * No request except DAV methods should ever receive the DAV handler. Heh. mod_dav also needs to handle GET and POST. Consider mod_dav_svn... the GET is definitley handled by mod_dav :-) But your general point is valid: mod_dav should not have set the handler if it was not going to handle the request. For the POST case, mod_dav was never intending to handle it -- only check the locks then return DECLINED for the "real" handler to deal with it. > * There must be a DAV handler registered run-very-first ... if the handler > is not DAV, yet there is a file, DAV checks the per-dir-config from the > request rec. If DAV is ON, the request must be locked. > * If the lock fails, dav satisfies the request with a 'Resource Locked' > response after some timeout. > * If the lock is granted, register a cleanup to release the lock. Euh... you misunderstand DAV locks. They are not per-request, but long-lived items. Somebody issues a LOCK request. Sometime later, they issue an UNLOCK request. In between those points, mod_dav needs to reject any POST operations to the resource unless the correct authorization and locktoken are present in the request. >... > We really need THREE pool scopes. The Connection, The Response > and The Request. This way, the response can outlive the request by > whatever time is needed to spool out the last of the sendfile fd or mmap > or whatever other -transient- method is required. Not sure how this relates to above, but I suspect from the mis-notion of [DAV] locks on a resource. In any case... Yup. This would be very cool, and will be very helpful when we move to a model where we have a single thread multiplexing responses to the clients. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: PHP POST handling
At 10:22 PM 10/2/2002, Roy T. Fielding wrote: >Output filters cannot handle methods -- only input filters can do that. >It sounds to me like you guys are just arguing past each other -- the >architecture is broken, not the individual modules. Just fix it. > >Greg is right -- the default handler is incapable of supporting any >method other than GET, HEAD, and OPTIONS, and must error if it sees >anything else. OTOH, mod_dav should not be monkeying with the content >hook if it isn't the content handler. If you don't fix both problems >then the security issue will resurface at a later time. Agreed; and yea - we are probably talking around each other. Because content filters -can- accept post bodies and modify the output of a disk resource (spooled by the default 'handler') ... we must have a way to -permit- the core filter to handle non-GET, HEAD and OPTIONS results. But that shouldn't be the default, and Greg and I agree at this point. The only question is what mechanism is used by a content filter to permit non-GET/HEAD/OPTIONS requests, such that a default OPTIONS request and the core handler accepts the FOO method that the content filter is prepared to deal with. In any case, this should be an mmn bump to assure that module authors have considered this change in POST behavior, and really isn't appropriate for the 2.0.43 release. It will be fixed (well, has already been fixed) immediately following that release. I'm using content filter, in this case, to describe a filter which is both an input body filter and an output body filter. Bill
[STATUS] (httpd-2.0) Wed Oct 2 23:45:20 EDT 2002
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2002/09/28 18:20:43 $] Release: 2.0.43 : in development. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Please consult the following STATUS files for information on related projects: * srclib/apr/STATUS * srclib/apr-util/STATUS * docs/STATUS Contributors looking for a mission: * just do an egrep on "TODO" and see what's there CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: CURRENT VOTES: * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: rbb, striker ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken * If the parent process dies, should the remaining child processes "gracefully" self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a "hot spare"). See: Message-ID: <[EMAIL PROTECTED]> Self-destruct: Ken, Martin Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, Jim, Justin Have 2 parents: +1: Jim -1: Justin, wrowe [for 2.0] +0: Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing) -0: Lars RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * There is a bug in how we sort some hooks, at least the pre-config hook. The first time we call the hooks, they are in the correct order, but the second time, we don't sort them correctly. Currently, the modules/http/config.m4 file has been renamed to modules/http/config2.m4 to work around this problem, it should moved back when this is fixed.rbb OtherBill offers that this is a SERIOUS problem. We do not sort correctly by the ordering arguments passed to the register hook functions. This was proven when I reordered the open_logs hook to attempt to open the error logs prior to the access logs. Possibly the entire sorting code needs to be refactored. * pipes deadlock on all platforms with limited pipe buffers (e.g. both Linux and Win32, as opposed to only Win32 on 1.3). The right solution is either GStein's proposal for a "CGI Brigade", or OtherBill's proposal for "Poll Buckets" for "Polling Filter Chains". * server pushed CGI's not working. This might be an interaction with the above pipes deadlock issue. PR: 8482 Message-ID: <[EMAIL PROTECTED]> * All handlers should al
[STATUS] (apache-1.3) Wed Oct 2 23:45:15 EDT 2002
APACHE 1.3 STATUS: -*-text-*- Last modified at [$Date: 2002/09/30 16:42:10 $] Release: 1.3.28-dev: In development 1.3.27: Tagged September 30, 2002. 1.3.26: Tagged June 18, 2002. 1.3.25: Tagged June 17, 2002. Not released. 1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002. 1.3.23: Tagged Jan 21, 2002. 1.3.22: Tagged Oct 8, 2001. Announced Oct 12, 2001. 1.3.21: Not released. (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001) 1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001. 1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001. 1.3.18: Tagged and rolled Not released. (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001) 1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001. 1.3.16: Not released. (Pulled because of vhosting bug. t/r Jan 20, 2001) 1.3.15: Not released. (Pulled due to CVS dumping core during the tagging when it reached src/os/win32/) 1.3.14: Tagged and Rolled Oct 10, 2000. Released/announced on the 13th. 1.3.13: Not released. (Pulled in the "first minutes" due to a Netware build bug) 1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th. 1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st. 1.3.10: Not released. (Pulled at "last minute" due to a build bug in the MPE port) 1.3.9: Tagged and rolled on Aug. 16. Released and announced on 19th. 1.3.8: Not released. 1.3.7: Not released. 1.3.6: Tagged and rolled on Mar. 22. Released and announced on 24th. 1.3.5: Not released. 1.3.4: Tagged and rolled on Jan. 9. Released on 11th, announced on 12th. 1.3.3: Tagged and rolled on Oct. 7. Released on 9th, announced on 10th. 1.3.2: Tagged and rolled on Sep. 21. Announced and released on 23rd. 1.3.1: Tagged and rolled on July 19. Announced and released. 1.3.0: Tagged and rolled on June 1. Announced and released on the 6th. 2.0 : Available for general use, see httpd-2.0 repository RELEASE SHOWSTOPPERS: * Current vote on 2 PRs for inclusion: Bugz #9181 (Unable to set headers on non-2XX responses) +1: Martin, Jim Gnats #10246 (Add ProxyConnAllow directive) +0: Martin (or rather -.5, see dev@ Message <[EMAIL PROTECTED]>) RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * htpasswd.c and htdigest.c use tmpnam()... consider using mkstemp() when available. Message-ID: <[EMAIL PROTECTED]> Status: * Dean's "unescaping hell" (unescaping the various URI components at the right time and place, esp. unescaping the host name). Message-ID: <[EMAIL PROTECTED]> Status: * Martin observed a core dump because a ipaddr_chain struct contains a NULL-"server" pointer when being dereferenced by invoking "httpd -S". Message-ID: <[EMAIL PROTECTED]> Status: Workaround enabled. Clean solution can come after 1.3.19 * long pathnames with many components and no AllowOverride None Workaround is to define with AllowOverride None, which is something all sites should do in any case. Status: Marc was looking at it. (Will asks 'wasn't this patched?') * Ronald Tschalär's patch to mod_proxy to allow other modules to set headers too (needed by mod_auth_digest) Message-ID: <[EMAIL PROTECTED]> Status: Available Patches (Most likely, will be ported to 2.0 as appropriate): * Backport of 2.0 ForceLanguagePriority directive /dist/httpd/contrib/patches/1.3/force_language_priority.patch Message-ID: <[EMAIL PROTECTED]> Status: * A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker <[EMAIL PROTECTED]> to more fully close some segfault potential. Message-ID: Status: Jim +1 (for 1.3.19), Martin +0 * Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires Message-ID: <[EMAIL PROTECTED]> Status: Martin +1, Jim +1, Ken +1 (on concept) * Raymond S Brand's path to mod_autoindex to fix the header/readme include processing so the envariables are correct for the included documents. (Actually, there are two variants in the patch message, for two different ways of doing it.) Message-ID: <[EMAIL PROTECTED]> Status: Martin +1(concept) * Jayaram's patch (10/27/99) for bugfix to mod_autoindex IndexIgnore should hide the files with this file- extension in directory listings. This was NOT happening because the total filename was being compared with the file-extension. Status: Martin +1(untested), Ken +1(untested) * Salvador Ortiz Garcia <[EMAIL PROTECTED]>' patch to allow DirectoryIndex to refer to URIs for non-static resources.
Re: PHP POST handling
Output filters cannot handle methods -- only input filters can do that. It sounds to me like you guys are just arguing past each other -- the architecture is broken, not the individual modules. Just fix it. Greg is right -- the default handler is incapable of supporting any method other than GET, HEAD, and OPTIONS, and must error if it sees anything else. OTOH, mod_dav should not be monkeying with the content hook if it isn't the content handler. If you don't fix both problems then the security issue will resurface at a later time. Roy
Re: PHP POST handling
At 06:23 PM 10/2/2002, Greg Stein wrote:
>On Tue, Oct 01, 2002 at 07:10:32PM -0500, William A. Rowe, Jr. wrote:
>> At 05:19 PM 10/1/2002, Greg Stein wrote:
>>...
>> >As long as it is understood that only *one* thing can consume the request
>> >body. Then the question arises: how do you arbitrate that? It would be nice
>> >to simply say "the handler is the consume" but that doesn't solve the case
>> >of a PHP script stored in an SVN repository. It is almost like we need some
>> >concept of stages leading up to request [body] processing and content
>> >generation.
>>
>> Wrong.
>
>Boy... not very subtle, are you? :-)
That's not something I'm accused of very often... no :-)
>> Multiple things can access the properties from the request.
>> Consider some form variables. One filter might be transforming on
>> variable X, while another performs some transformation on variable Z.
>> And they use the same storage for all small bits of the POST.
>
>Well... if by "properties" you mean the headers: sure. But only one person
>understands the POST body, and only one should be reading it.
No, there are several well defined content-types for POST bodies, all
of which define variables, or properties. application/x-www-form-urlencoded,
multipart/form-data or application/xml are all reasonably well defined.
Others would clearly be considered 'not available' in unpacked form.
While the filters could all serialize and review the contents, the majority
of applications would probably not be interested in the contents, and
the others must be prepared to decipher the obscure client body.
>> In the case of upload requests, one consumer must 'sign up' to stream
>> the file, and provide a method for retrieving the contents if anyone else
>> cares {for the duration of the request.} In theory, that consumer is the
>> script that wants to persist the POSTed file upload. If nobody wants
>> to capture a huge POST body, we may end up with a tmpfile method,
>> but if the file will be persisted, there is no reason to stow it twice.
>
>This seems to assume that Apache [core] is processing POST bodies in some
>way, and then providing APIs for other modules/scripts to access the
>processed data.
No, we are suggesting that apreq be built into httpd. At the same time,
the Apache apreq filter would ONLY process the client's body if an apreq
consumer of this specific request injects the apreq filter (through some
simple API) into the request process prior to the handler processing
the request. Multiple calls to inject the apreq filter would resolve to a
single instance of the apreq filter and decomposition.
>I'd be very leery of automatic POST body processing in any form. Providing
>standard functions? Sure. And that is what libapreq is about, right? :-)
Automatic? Only by request. If a tree falls and noone is listening, any
sound it made is wasted. Same with apreq ... I sure don't want to waste
memory or cpu breaking apart POST bodies with no consumers :-)
>> >But they are two modes of operation. In one, you generate the original
>> >content (e.g. a PROPFIND or GET response against a database), in the
>> >other you're filtering content.
>>
>> In both cases you are transforming a PHP script into the resulting
>> output from processing the script. No difference, truly.
>
>At a technical level, no, not really. But the problem is that the filter
>stack is about filtering the *content*. If the *script* is travelling
>through the filter chain, then you've got issues :-)
I don't really see any issues. Please elaborate :-)
>The workaround to that is to always ensure that the script processor is the
>first filter on the chain. But that seems kind of hacky... you could end up
>with some contention there, with filters trying to jocky their way into
>"first". What if a filter got itself in front of PHP? Uh oh. (yes, it would
>be fine if the filter knows it is processing a script, but if it *doesn't...)
Why 'first'? Perhaps I have a mixture of javascript and php in a composite
document. Perhaps I want one, then the other to process the data. In any
case, I (the admin) should be able to order these filters. Right now we are
really not there in terms of ordering, but we all agree that's got to be fixed.
>As an example of fighting for first: the OLD_WRITE filter. How do we
>arbitrate that "first" spot between PHP (or some other script processor) and
>OLD_WRITE?
>
>That is why I suggested there might be a need for some kind of staged
>process where we manage non-content data.
If we want to have a specific domain for 'parser/scripts' in the stack, just
like we have request and connection oriented filters today, that would be
fine by me. See my comments on ordering above.
>>...
>> >> And that said, you can't break POST to the default handler, please
>> >> revert that change.
>> >
>> >The POST behavior before my fix was a regression against 1.3. Its existence
>> >was to support the PHP-processing-as-a-filter implementation. The impac
Re: Authentication
On Wednesday, October 2, 2002, at 08:07 PM, Joshua Slive wrote: > > > > > require valid-user > > > > > require valid-user > > > This has the effect of leaving GET unrestricted, according to the bug > report. Is this correct behavior? It seems like, since the other > methods > are not change by the , the require should still apply to > them. > what jerry brought up here definitely seems like a bug to me. Not sure why folks are in such disbelief :) i'll check into it - sterling
Re: Authentication
* André Malo wrote: > # or: use advantages of PCRE > which have to be turned on, of course [...] nd
Re: RLimitNPROC behaviour question
On Thu, Oct 03, 2002 at 03:22:35AM +0200, André Malo wrote: > http://httpd.apache.org/docs-2.0/mod/core.html#rlimitnproc says: > > | Note: If CGI processes are not running under userids other than the > | web server userid, this directive will limit the number of processes > | that the server itself can create. Evidence of this situation will > | be indicated by "cannot fork" messages in the error_log. > > I looked into the kernel code and played around with strace and found > that it's not true at least for linux 2.2 and 2.4. > > the rlimit properties will be set after forking and apply only to the > forked process and it's children. So it cannot influence the server > processes in such way. But my experiences with other OSes are very > small. Can someone leave a word on behaviour of other OSes? > > If I'm totally wrong, please tell me ;-) The directive refers only to the CGI processes, not the server processes (the wording can be confusing) Cheers Daniel -- Teach Yourself Apache 2 -- http://apacheworld.org/ty24/
Re: Authentication
* Jerry Baker wrote:
> If there's no way to have a LimitExcept *and* separate directories
> requiring authentication for everything, how in the world could you
> have a DAV enabled server while still being able to restrict
> directories with authentication requirements?
There are several ways. For instance:
# turn to
Require user bob
...
AuthType Basic
AuthUserFile "D:/Web/htpasswd"
AuthName "Protected Area"
Require valid-user
# or: use advantages of PCRE
Require user bob
...
AuthType Basic
AuthUserFile "D:/Web/htpasswd"
AuthName "Protected Area"
Require valid-user
nd
--
sub the($){+shift} sub answer (){ord q
[* It is always 42! *] }
print the answer
# André Malo # http://www.perlig.de/ #
RLimitNPROC behaviour question
http://httpd.apache.org/docs-2.0/mod/core.html#rlimitnproc says: | Note: If CGI processes are not running under userids other than the | web server userid, this directive will limit the number of processes | that the server itself can create. Evidence of this situation will | be indicated by "cannot fork" messages in the error_log. I looked into the kernel code and played around with strace and found that it's not true at least for linux 2.2 and 2.4. the rlimit properties will be set after forking and apply only to the forked process and it's children. So it cannot influence the server processes in such way. But my experiences with other OSes are very small. Can someone leave a word on behaviour of other OSes? If I'm totally wrong, please tell me ;-) nd -- s;.*;aoaaaoaaoaaaom:a:alataa:aaoat:a:a:a maoaa:a:laoata:a:oia:a:o:a:m:a:o:alaoooat:aaool:aaoaa matooololaaatoto:aaa:o:a:o:m;;s:\s:\::g;y;mailto:; \40\51/\134\137|ndparker <[EMAIL PROTECTED]>;;print;
Re: Authentication
On Wed, 2 Oct 2002, Jerry Baker wrote: > Joshua Slive says: > > This has the effect of leaving GET unrestricted, according to the bug > > report. Is this correct behavior? It seems like, since the other methods > > are not change by the , the require should still apply to > > them. > > I agree. The LimitExcept directive implies that the limit will apply to > everything with the exception of what follows (POST, HEAD, GET, etc.). > "Except" is negative in nature - meaning exclusion. It implies that > nothing will be done to those requests since the directive says they are > to be excluded. Since Apache uses the LimitExcept directive to apply > some sort of context to the HTTP requests in that directive, it's not > really excluding those requests from the directive. It's semantics, but > important ones. > > Users get clues about how config directives work by the meaning of the > words used. In this case, "except" is misleading. It should be changed > to . There is a difference. No. should be corrected not to touch the other methods. Otherwise, things like this wouldn't work: require valid-user order deny,allow deny from badguy.com Joshua.
Re: Authentication
Joshua Slive says: > This has the effect of leaving GET unrestricted, according to the bug > report. Is this correct behavior? It seems like, since the other methods > are not change by the , the require should still apply to > them. I agree. The LimitExcept directive implies that the limit will apply to everything with the exception of what follows (POST, HEAD, GET, etc.). "Except" is negative in nature - meaning exclusion. It implies that nothing will be done to those requests since the directive says they are to be excluded. Since Apache uses the LimitExcept directive to apply some sort of context to the HTTP requests in that directive, it's not really excluding those requests from the directive. It's semantics, but important ones. Users get clues about how config directives work by the meaning of the words used. In this case, "except" is misleading. It should be changed to . There is a difference. -- Jerry Baker
Re: Authentication
Joshua Slive says: > This has the effect of leaving GET unrestricted, according to the bug > report. Is this correct behavior? It seems like, since the other methods > are not change by the , the require should still apply to > them. That's what I thought at first, but there are two ways of looking at it. At first I looked at LimitExcept as a negative declaration. Negative in the sense that it meant "ignore GET HEAD POST for the following directives". Instead, Apache is treating it as a positive declaration that is saying, "do not limit GET HEAD POST". It's a fine distinction, but one that may cause confusion. -- Jerry Baker
Re: Authentication
On Wed, 2 Oct 2002, William A. Rowe, Jr. wrote: > YES! All that merging stuff is true. But let's go back to the original problem: require valid-user require valid-user This has the effect of leaving GET unrestricted, according to the bug report. Is this correct behavior? It seems like, since the other methods are not change by the , the require should still apply to them. Joshua.
Re: PHP POST handling
On Tue, Oct 01, 2002 at 07:10:32PM -0500, William A. Rowe, Jr. wrote:
> At 05:19 PM 10/1/2002, Greg Stein wrote:
>...
> >As long as it is understood that only *one* thing can consume the request
> >body. Then the question arises: how do you arbitrate that? It would be nice
> >to simply say "the handler is the consume" but that doesn't solve the case
> >of a PHP script stored in an SVN repository. It is almost like we need some
> >concept of stages leading up to request [body] processing and content
> >generation.
>
> Wrong.
Boy... not very subtle, are you? :-)
> Multiple things can access the properties from the request.
> Consider some form variables. One filter might be transforming on
> variable X, while another performs some transformation on variable Z.
> And they use the same storage for all small bits of the POST.
Well... if by "properties" you mean the headers: sure. But only one person
understands the POST body, and only one should be reading it.
> In the case of upload requests, one consumer must 'sign up' to stream
> the file, and provide a method for retrieving the contents if anyone else
> cares {for the duration of the request.} In theory, that consumer is the
> script that wants to persist the POSTed file upload. If nobody wants
> to capture a huge POST body, we may end up with a tmpfile method,
> but if the file will be persisted, there is no reason to stow it twice.
This seems to assume that Apache [core] is processing POST bodies in some
way, and then providing APIs for other modules/scripts to access the
processed data.
I'd be very leery of automatic POST body processing in any form. Providing
standard functions? Sure. And that is what libapreq is about, right? :-)
>...
> >But they are two modes of operation. In one, you generate the original
> >content (e.g. a PROPFIND or GET response against a database), in the other
> >you're filtering content.
>
> In both cases you are transforming a PHP script into the resulting
> output from processing the script. No difference, truly.
At a technical level, no, not really. But the problem is that the filter
stack is about filtering the *content*. If the *script* is travelling
through the filter chain, then you've got issues :-)
The workaround to that is to always ensure that the script processor is the
first filter on the chain. But that seems kind of hacky... you could end up
with some contention there, with filters trying to jocky their way into
"first". What if a filter got itself in front of PHP? Uh oh. (yes, it would
be fine if the filter knows it is processing a script, but if it *doesn't...)
As an example of fighting for first: the OLD_WRITE filter. How do we
arbitrate that "first" spot between PHP (or some other script processor) and
OLD_WRITE?
That is why I suggested there might be a need for some kind of staged
process where we manage non-content data.
>...
> >> And that said, you can't break POST to the default handler, please
> >> revert that change.
> >
> >The POST behavior before my fix was a regression against 1.3. Its existence
> >was to support the PHP-processing-as-a-filter implementation. The impact of
> >adding the POST "feature" to the default handler was never really detected
> >until we uncovered it via a bug in mod_dav. Since this regression was found,
> >I went in and fixed it. Unfortunately, that breaks PHP :-) But I think the
> >PHP integration is broken and needs to be fixed.
> >
> >While new PHP integration is being solved, we can *temporarily* revert the
> >change so that PHP users aren't inconvenienced while the integration is
> >worked on. But the default_handler fix does need to go in to prevent the
> >regression.
> >
> >(I term it a regression because 1.3 didn't do it, and POSTing to something
> > which isn't going to handle the posted content is not right; we should be
> > generating an error that states the POST is not allowed for that resource;
> > that is what 405 is all about)
>
> We should continue this discussion after the change is reverted,
> and let's find a better answer.
The default handler shouldn't be serving up the file for a POST. The
original change that did that was wrong.
> Going back to the apreq input filter, I can see where it would share
> with the core if anyone registered to review the client body. If someone
> does, the handler could be toggled to accept POST. If nobody registers,
> then we could decline POST.
I like this.
However, it really shouldn't be tied to POST, but should work for any
method. And it would seem to be a new request_rec field. However, to avoid
an MMN bump, I might suggest that we put the flag into the core config
record (core_request_config structure) and an API to set the flag.
So the next question then becomes: what to call the API function? Maybe
ap_method_requires_script()? It basically says "normally, this method does
not return the resource as content, but I require it because I'll interpret
it as a script to process this method." Scri
Re: Authentication
YES! The pattern is: (and .htaccess'es within those directories) with the s parsed in the appropriate container. We repeat because the original could have changed in translate_name, and yes, the URI permissions or restrictions always override any file-based permissions. E.g., you could have a DocumentRoot /thatpath Alias /secure-dav/ /thatpath/ Dav On and even though DAV is OFF in the ... the server will still allow a DAV view within the /secure-dav/... namespace. This is how 1.3 and 2.0 have always worked. Bill At 06:06 PM 10/2/2002, Jerry Baker wrote: >André Malo says: >>Sorry, I can't believe, that it worked ever before the way you >>described. Are you sure, that you've changed nothing else? > >So Location matches are even more important than .htaccess matches? That doesn't make >sense. I would think that a directive in .htaccess is always more specific than one >in the config files. > >-- >Jerry Baker
Re: cvs commit: httpd-2.0/server core.c util_script.c
If someone reverts that -part- of the commit, and changes CHANGES to reflect this group decision, I will bring in that commit tomorrow a.m. before the final tag and roll. Sorry if I wasn't clear on the consensus decision. +1. Bill At 05:54 PM 10/2/2002, Joshua Slive wrote: >On Wed, 2 Oct 2002, Marc Slemko wrote: >> Lets not encode env variables, as we discussed earlier. >> >> Escaping them is bogus and doesn't solve anything since there are all >> sorts of variables that aren't and shouldn't be encoded. > >+1 to what Marc says. The encoding serves no purpose. Preventing the >sample cgi scripts from being included in a "make install" would be a >great idea. > >Joshua.
Re: Authentication
André Malo says: > Sorry, I can't believe, that it worked ever before the way you > described. Are you sure, that you've changed nothing else? If there's no way to have a LimitExcept *and* separate directories requiring authentication for everything, how in the world could you have a DAV enabled server while still being able to restrict directories with authentication requirements? -- Jerry Baker
Re: Authentication
André Malo says: > Sorry, I can't believe, that it worked ever before the way you > described. Are you sure, that you've changed nothing else? So Location matches are even more important than .htaccess matches? That doesn't make sense. I would think that a directive in .htaccess is always more specific than one in the config files. -- Jerry Baker
Re: Authentication
André Malo says: > * Jerry Baker wrote: > >> Except for that directory is configured to require authentication. See >> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13218 > > sections override , see > http://httpd.apache.org/docs-2.0/sections.html#mergin > > Sorry, I can't believe, that it worked ever before the way you > described. Are you sure, that you've changed nothing else? Absolutely. My config file backups show that before yesterday, I hadn't changed anything in that file for 5 months. -- Jerry Baker
Re: Authentication
* Jerry Baker wrote: > Except for that directory is configured to require authentication. See > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13218 sections override , see http://httpd.apache.org/docs-2.0/sections.html#mergin Sorry, I can't believe, that it worked ever before the way you described. Are you sure, that you've changed nothing else? nd -- Treat your password like your toothbrush. Don't let anybody else use it, and get a new one every six months. -- Clifford Stoll (found in ssl_engine_pphrase.c)
Re: cvs commit: httpd-2.0/server core.c util_script.c
On Wed, 2 Oct 2002, Marc Slemko wrote: > Lets not encode env variables, as we discussed earlier. > > Escaping them is bogus and doesn't solve anything since there are all > sorts of variables that aren't and shouldn't be encoded. +1 to what Marc says. The encoding serves no purpose. Preventing the sample cgi scripts from being included in a "make install" would be a great idea. Joshua.
Re: Authentication
Greg Stein says: > On Tue, Oct 01, 2002 at 11:13:55PM -0600, Jerry Baker wrote: >> Jerry Baker says: >> > Jerry Baker says: >> > > Yet, when I access that directory, I am just given an empty directory >> > > listing. No prompt for a username or pass. >> > >> > Nevermind. It's just something else that DAV broke. Turning off DAV >> > fixed the problem. >> >> Please accept my apologies for the spam. The problem is not with DAV, >> but with . When I remove the LimitExcept >> directive, basic authentication works again. Makes no difference whether >> Dav On or Dav Off. > > Right. You were saying "require authentication *except* for those methods", > so (of course) a GET request would not demand a user/pass. Except for that directory is configured to require authentication. See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13218 -- Jerry Baker
Re: Authentication
On Tue, Oct 01, 2002 at 11:13:55PM -0600, Jerry Baker wrote: > Jerry Baker says: > > Jerry Baker says: > > > Yet, when I access that directory, I am just given an empty directory > > > listing. No prompt for a username or pass. > > > > Nevermind. It's just something else that DAV broke. Turning off DAV > > fixed the problem. > > Please accept my apologies for the spam. The problem is not with DAV, > but with . When I remove the LimitExcept > directive, basic authentication works again. Makes no difference whether > Dav On or Dav Off. Right. You were saying "require authentication *except* for those methods", so (of course) a GET request would not demand a user/pass. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/server core.c util_script.c
On 2 Oct 2002 [EMAIL PROTECTED] wrote:
> Index: util_script.c
> ===
> RCS file: /home/cvs/httpd-2.0/server/util_script.c,v
> retrieving revision 1.79
> retrieving revision 1.80
> diff -u -r1.79 -r1.80
> --- util_script.c 23 Jun 2002 06:15:03 - 1.79
> +++ util_script.c 2 Oct 2002 21:35:57 - 1.80
> @@ -266,7 +266,8 @@
>
>apr_table_addn(e, "SERVER_SIGNATURE", ap_psignature("", r));
>apr_table_addn(e, "SERVER_SOFTWARE", ap_get_server_version());
> -apr_table_addn(e, "SERVER_NAME", ap_get_server_name(r));
> +apr_table_addn(e, "SERVER_NAME",
> + ap_escape_html(r->pool, ap_get_server_name(r)));
>apr_table_addn(e, "SERVER_ADDR", r->connection->local_ip); /* Apache */
>apr_table_addn(e, "SERVER_PORT",
> apr_psprintf(r->pool, "%u", ap_get_server_port(r)));
>
Lets not encode env variables, as we discussed earlier.
Escaping them is bogus and doesn't solve anything since there are all
sorts of variables that aren't and shouldn't be encoded.
Re: Authentication
At 11:11 PM 10/1/2002, Jerry Baker wrote: >Currently, authentication is broken with the standard Windows config file and current >HEAD. Where is the documentation on the complete mess-up of the auth modules and how >to get it working again? The documentation is not complete, nor hooked up into the main indexes and directives pages, therefore we aren't releasing the new auth schema, and therefore little reason to worry. Exactly the reason this aught to have been committed on a branch, or better yet, to the 2.1 tree. Enough ranting. 2.0.43 will be a bugfix and security release, and doesn't include this pretty major reorganization. Need to put the docs and reconfig front and center after .43 goes out the door, or we should just relegate that code to it's own branch until it's ready. I remember we talked about some reasonable time frame (2 weeks?) that the tree could be broken. We are kind of stretching that time table already. Bill
Release of 2.0.43
Since all of these issues are now public, I'm moving the discussion over
to the dev list.
First, +1 to the patch below. With nothing else put forward, this
is the patch that will go into 2.0.43
I've already moved it to apply_to_2.0.42 since, after the public
disclosure, there is nothing standing in the way of revealing the
fix to this vulnerability posted (prematurely) this morning on
bugtraq.
Ryan indicates that the fix for POST applied to dav/main/mod_dav.c
he committed earlier solves that problem.
There is a tag WROWE_2_0_43_PRE2 containing the bugfixes
applied to the tree since 2.0.42, excluding the changes for --bindir,
Berkley 4.1 and auth.
Please check out and test that tag. Per my own and Brad Nicholes
observations, it builds on Win32 and Netware.
I'm prepared to tag and roll this release tommorow before 9am PDT.
Bill
>Subject: [PATCH] Re: Apache 404 Page Security Hole
>From: Brian Pane <[EMAIL PROTECTED]>
>Date: 21 Sep 2002 10:27:54 -0700
>
>Here's a patch that escapes the address produced by
>ap_server_signature().
>
>In the patch, I'm also HTML-escaping the SERVER_NAME
>environment variable that's set for CGI and SSI requests.
>A CGI script could use SERVER_NAME in some context other
>than HTML, of course, but I think it's safe to do the
>escaping because it only affects '<', '>', and '&',
>which shouldn't appear in a valid hostname.
>
>Brian
>
>On Sat, 2002-09-21 at 07:15, Dirk-Willem van Gulik wrote:
>>
>> I've been off line for the last few days - was this acknowledged (to help
>> us keep this queit until patched). Cursory test seems to suggest it is
>> valid.
>>
>> Dw
>>
>> On Fri, 20 Sep 2002, Matthew Murphy wrote:
>>
>> > In most cases, the Apache HTTPd protects well against cross-site scripting
>> > in its error output. However, the "" tag that Apache returns is
>> > vulnerable to a cross-site scripting issue. The problem occurs because of
>> > wildcard support on some hosts. If a domain pointing to an Apache HTTPd has
>> > wildcards enabled (in other words, all sub-domains that do not exist simply
>> > re-direct to the primary one), HTML markup can be passed as a subdomain, and
>> > apache will return it.
>> >
>> > This is a serious vulnerability as it allows stealing cookies from any
>> > Apache domain that uses them; this could enable theft of session
>> > authentication data or other personal information from users of some sites.
>> >
>> > http://%3CIMG%20SRC%3D%22%22%20ONERROR%3D%22document%2Edomain%3D%27apachesit
>> > e%2Eorg%27%3Balert%28document%2Ecookie%29%22%3E.apachesite.org/404
>> >
>> > Will return this on a working Apache server with wildcards allowed:
>> >
>> > Apache/2.0.39 Server at > > onerror="document.domain='apachesite.org';alert(document.cookie)">.apachesit
>> > e.org Port 80
Index: server/core.c
===
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.205
diff -u -r1.205 core.c
--- server/core.c 16 Sep 2002 13:11:55 - 1.205
+++ server/core.c 21 Sep 2002 17:22:11 -
@@ -2240,12 +2240,15 @@
return apr_pstrcat(r->pool, prefix, "" AP_SERVER_BASEVERSION
" Server at mailto:";,
r->server->server_admin, "\">",
- ap_get_server_name(r), " Port ", sport,
+ ap_escape_html(r->pool, ap_get_server_name(r)),
+ " Port ", sport,
"\n", NULL);
}
return apr_pstrcat(r->pool, prefix, "" AP_SERVER_BASEVERSION
- " Server at ", ap_get_server_name(r), " Port ", sport,
+ " Server at ",
+ ap_escape_html(r->pool, ap_get_server_name(r)),
+ " Port ", sport,
"\n", NULL);
}
Index: server/util_script.c
===
RCS file: /home/cvs/httpd-2.0/server/util_script.c,v
retrieving revision 1.79
diff -u -r1.79 util_script.c
--- server/util_script.c23 Jun 2002 06:15:03 - 1.79
+++ server/util_script.c21 Sep 2002 17:22:11 -
@@ -266,7 +266,8 @@
apr_table_addn(e, "SERVER_SIGNATURE", ap_psignature("", r));
apr_table_addn(e, "SERVER_SOFTWARE", ap_get_server_version());
-apr_table_addn(e, "SERVER_NAME", ap_get_server_name(r));
+apr_table_addn(e, "SERVER_NAME",
+ ap_escape_html(r->pool, ap_get_server_name(r)));
apr_table_addn(e, "SERVER_ADDR", r->connection->local_ip); /* Apache */
apr_table_addn(e, "SERVER_PORT",
apr_psprintf(r->pool, "%u", ap_get_server_port(r)));
Your application is on GNUWin II
Hi, We are very pleased to inform you, that we have included your application (for which you are listed as author or contact person) into GNUWin II (http://gnuwin.epfl.ch). We would like to thank you for your contribution to the world of free software. GNUWin shall help to introduce users to free software, to show that it exists (and works!) and to ease a future migration to an entirely free system, like GNU/Linux for instance. GNUWin itself is meant to be 'libre' (free in the sens of the GPL). You can find iso images of GNUWin on the Swiss Sunsite Mirror at ftp://sunsite.cnlab-switch.ch/mirror/gnuwin/ http://sunsite.cnlab-switch.ch/ftp/mirror/gnuwin/ or from our (for the moment somewhat loaded) site at http://gnuwin.epfl.ch/iso/ Note: Some few applications have been added very recently only, and may not be on the ISO image yet. Sorry about that. Best regards GNU Generation (http://gnugeneration.epfl.ch) Bonjour ! Nous avons le plaisir de vous annoncer que votre application a été sélectionnée pour figurer sur GNUWin, et nous vous remercions de tout coeur pour votre contribution aux Logiciels libres et à l'open source. GNUWin-II est une compilation de logiciels libres et open source pour Windows, destinée à apporter aux utilisateur la puissance des logiciels libres, et de faciliter une future transition vers GNU/Linux en les introduisant à des logiciels qu'ils pourront utiliser sur leur nouvelle plateforme. Vous pouvez visiter notre projet à l'adresse http://gnuwin.epfl.ch , et télécharger l'image ISO sur http://gnuwin.epfl.ch/iso/ ou (de préférence) sur notre miroir sur Swiss SunSITE à ftp://sunsite.cnlab-switch.ch/mirror/gnuwin/ http://sunsite.cnlab-switch.ch/ftp/mirror/gnuwin/ Vos commentaires et suggestions sont naturellement les très bienvenus, et, en vous remerciant encore pour votre travail utile à la communauté, nous vous prions d'agréer les compliments de toute l'équipe de GNU Generation (http://gnugeneration.epfl.ch)
A survey about handling bugs in open source projects
Hello all Http contributors, I am conducting a survey about the way defects (or bugs-I use these two words interchangeably) are handled in open source software projects. It is very easy to fill out. It consists of three short sections which can be completed at once or in different sessions. The survey can be found in the address: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html This survey includes questions that can be answered by developers,testers, bug fixers, bug database owners, and project managers. I would greatly appreciate if you could visit the above web page and fill out the survey. I am sure you will find the questions very interesting and thought provoking. We need the help of all contributors of Http in the above roles to understand how we can use bugs data collected in your project for software engineering research. Nowadays, there is a huge amount of bug data on the Internet collected during the development of all open source products. A bug database include useful information to identify high-risk, problem-prone modules (components) in the software. It is also possible to measure these problem-prone components using several complexity metrics (McCabe's cyclomatic complexity, Halstead's metrics, etc.), since the source code is available. If a characterization, which is generalizable across many projects (sub-projects) could be made in terms of complexity, focused quality improvement would become possible in the future projects. So far, in the literature, there is quite amount of evidence that 80 percent of the problems occur from 20 percent of the modules (or software components), which gives hope toward tremendous quality increase, time savings, and increased success in the open source projects. Also a bug database includes useful information about the efficiency of development. For example, if a lot of bugs related to design of the system are found after release, when coding bugs are expected more, then this may indicate that the design or architecture of the system was done cursory. Of course, these kinds of conclusions would require some kind of classification of bugs according to their insertion time after they get fixed. However, before trying to find an answer to the questions like above, our first step is to understand if the available data is usable for empirical research purposes. This means having an idea about the consistency of bug reports and fixes, accuracy of data, completeness of the data, etc. At this point, we need your help. By filling out this survey, you will help us understand availability, representativeness, and characteristics of the data in the bug database of your project. I'd like to stress that the purpose of this survey is only and only research. Open source development gained a very good momentum in the last decade. We hope that outcomes of our research will help even increase this momentum. We will acknowledge the help of all supporting communities when mentioning our results. In addition to these goals, we also think that filling out this short survey can lead to some immediate brain-storming in individuals and groups, and exchange of ideas among the Http community, which will be useful too. As I said, you will find the survey questions interesting. If you'd prefer to learn more about our research, I included a link in the above web page of our survey. This link provides more information about our research. Once more, your contribution is very important to us. Please visit http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html and fill out our survey. We greatly appreciate your helps. Please contact me for any question you might have. Thanks -- *** A. Gunes Koru Research Assistant, Ph.D. Student Southern Methodist University Computer Science and Engineering Department 6425 North Ownby Drive Science and Information Building Room 317 Dallas, TX 75205 Home: 214 691 5633 Work: 214 768 2005 Cell: 214 893 7311 http://www.seas.smu.edu/~gkoru Email: [EMAIL PROTECTED] ***
Re: Multiple handlers within a module?
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > On Wed, Sep 25, 2002 at 03:24:32PM -0700, Will Hartung wrote: > > It is not at all clear to me using the new 2.0 modules how I associate the > > different names to our module. I see the ap_hook_handler(), but it only > > wants the function, and doesn't seem to have a way of binding a name to that > > function. > > It doesn't. All handlers are invoked on all requests. So, there is > no relationship between the invocation of a handler and whether it > needs to run. The handler must check whether its handler string is > the same as r->handler. If not, it is expected to return DECLINED. > > > I also noticed within the mod_example, that they check the actual handler > > name when the function is called. Is that necessary? Is that the actual > > mechanism? > > Yes. -- justin This thread is definitely a FAQ. Anybody up to sticking it here? http://httpd.apache.org/docs-2.0/developer/modules.html -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: [PATCH] mod_cgid tells APR that an os file is a pipe
Jeff Trawick <[EMAIL PROTECTED]> writes: > The following patch adds a way for an APR app to say that the > apr_file_t being created from an os file should be treated as a pipe. c'mon folks, I was counting on somebody to tell me how stupid this patch was :) I have a bad attitude about the file/pipe/socket games in APR which may prevent me from seeing the "right" fix given the current API. mod_cgid does: > -apr_os_file_put(&tempsock, &sd, 0, r->pool); > +apr_os_file_put_ex(&tempsock, &sd, 1, 0, r->pool); APR provides: > /** > + * convert the file from os specific type to apr type. > + * @param file The apr file we are converting to. > + * @param thefile The os specific file to convert > + * @param ispipe Whether or not the descriptor should be treated as a pipe > + * @param flags The flags that were used to open this file. > + * @param cont The pool to use if it is needed. > + * @remark On Unix, it is only possible to put a file descriptor into > + * an apr file type. > + */ > +APR_DECLARE(apr_status_t) apr_os_file_put_ex(apr_file_t **file, > + apr_os_file_t *thefile, int is_pipe, > + apr_int32_t flags, apr_pool_t *cont); -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
