Re: handling of security issues in alphas?
On 1/8/2011 8:50 AM, Stefan Fritsch wrote: > On Saturday 08 January 2011, s...@apache.org wrote: >> Author: sf >> Date: Sat Jan 8 14:29:12 2011 >> New Revision: 1056713 >> >> URL: http://svn.apache.org/viewvc?rev=1056713&view=rev >> Log: >> Fix a bug in authz logic merging which caused >> section->op == AUTHZ_LOGIC_AND >> auth_result == AUTHZ_DENIED_NO_USER >> child_result == AUTHZ_GRANTED >> to return AUTHZ_GRANTED instead of AUTHZ_DENIED_NO_USER. >> >> While there, refactor the if blocks to make them a bit more >> readable. >> >> Modified: >> httpd/httpd/trunk/CHANGES >> httpd/httpd/trunk/modules/aaa/mod_authz_core.c > > This was broken since r964156 / 2.3.8. > > Is there some agreed upon policy how to handle security issues that > only affect alphas and/or betas? Do we need a CVE id? > > IMO: No for alphas, but maybe yes for betas? Well, if it was a concern, it wouldn't be committed until we were prepared to release the replacement, which is why such patches are first discussed at the secur...@httpd.a.o by exclusively project members who are willing to review security-related changes. Since the ASF and others run alphas in production, these certainly require appropriate handling, alpha beta or GA. The only question is whether this represents an undisclosed and unanticipated security flaw, or is a blatent and obvious bug in behavior. If it's the former, it gets a CVE. If it's the later, it just gets fixed. Because the code is in the auth section does not automatically elevate it to a 'security vulnerability'. What would elevate it is unexpected or inconsistent results that would not be plainly observed by every administrator setting up this configuration.
Re: svn commit: r1056448 - /httpd/httpd/trunk/docs/manual/mod/mod_log_config.xml
On 1/8/2011 5:53 AM, Graham Leggett wrote: > > I've got a better idea. Why not collaborate with the other people in this > project instead > of attempting to bully them with the threat of yet-another-veto? Before you try to mis-characterize me as a bully or as veto-happy, please compare the number of vetos I have in fact cast, here and/or at APR, over 10 years, with a good hard look at their causes and resolutions. Then you are free to compare these with other httpd committers at the resolution ratio. You removed a valid caution to users, I objected with specifics, Ruediger solved, you fixed. Please don't feel put upon every single time someone finds an objection to your commit, it's enough to just be thankful we are all here crosschecking each others work. As you close with, > This resulted in r1056693, and a resolution to the issue. which is exactly as it should work. If you objected to that sort of a solution we might be at a stalemate, and I might be reverting, but I believe we are all satisfied unless there are others here who still object to this becoming a non-experimental feature.
Re: svn commit: r1056448 - /httpd/httpd/trunk/docs/manual/mod/mod_log_config.xml
On 1/8/2011 4:15 AM, Ruediger Pluem wrote: > > How about > > This directive should be used with caution as a crash might cause loss > of logging data. > > or something similar. Doc's wordsmithes please chime in :-). Yup, that's the gist of it. Thanks for wordsmithing, and thanks Graham for committing! [If you are looking for wordsmiths, email docs@ where they know to pay attention to the plea :-]
Re: Issues with
- "Stefan Fritsch" wrote: > Hi, > > there are some serious problems with how is implemented right > > now: > > 1) It is hooked into ap_file_walk() which is only called in the > map_to_storage hook. This means that it is not executed for non-file > requests like ProxyPass'ed requests. This reduces its usefulness a > great deal. > > 2) ap_file_walk() will happily reuse a cached file walk result if the > > file name is identical (see the 'strcmp(test_file, cache->cached) == > 0' check). While I haven't been able to trigger wrong behaviour so > far, I am pretty sure that this will give the wrong result for in > > some corner cases. > > 3) can be used at VHost level and inside blocks. But > > it cannot be used inside blocks (trying to do so will give > > a startup error), which reduces the usefulness even more. > > 4) blocks inside blocks are silently ignored. > > I am open for ideas how to solve these problems. One idea I had is the > > following: > > Create a new function ap_if_walk() that handles the sections and > > is called after ap_location_walk(). Store the sections in a > separate array core_dir_config->sec_if, just like sections are > stored in core_dir_config->sec_files. This should allow to use > inside , , and . It may be surprising that In how far would this impact performance? > all sections would be applied last, even if they appeared inside > . But I think this could be solved with documentation. > > More ideas? Comments? > > Cheers, > Stefan -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/
Issues with
Hi, there are some serious problems with how is implemented right now: 1) It is hooked into ap_file_walk() which is only called in the map_to_storage hook. This means that it is not executed for non-file requests like ProxyPass'ed requests. This reduces its usefulness a great deal. 2) ap_file_walk() will happily reuse a cached file walk result if the file name is identical (see the 'strcmp(test_file, cache->cached) == 0' check). While I haven't been able to trigger wrong behaviour so far, I am pretty sure that this will give the wrong result for in some corner cases. 3) can be used at VHost level and inside blocks. But it cannot be used inside blocks (trying to do so will give a startup error), which reduces the usefulness even more. 4) blocks inside blocks are silently ignored. I am open for ideas how to solve these problems. One idea I had is the following: Create a new function ap_if_walk() that handles the sections and is called after ap_location_walk(). Store the sections in a separate array core_dir_config->sec_if, just like sections are stored in core_dir_config->sec_files. This should allow to use inside , , and . It may be surprising that all sections would be applied last, even if they appeared inside . But I think this could be solved with documentation. More ideas? Comments? Cheers, Stefan
Re: Inspiration for mod_lua
On Fri, Dec 31, 2010 at 12:48 AM, William A. Rowe Jr. wrote: > On 12/30/2010 8:09 PM, Joe Schaefer wrote: >> >> I mean take the CMS I just wrote with mod_perl. It's 2K LOC, uses a custom >> map_to_storage handler, and defers a good chunk of its (sub)requests to httpd >> for things like autoindex and negotiation and plain-old file serving, and >> forwards >> a user's basic auth creds to the subversion server. That isn't remotely >> feasible >> with mod_fcgi, I'd have to reimplement all that functionality my app, which >> is >> a waste. > > You are right, for content fcgid would be fine, but for the rest we'd hope > that > mod_lua is much less of a memory hog, and can accomplish those same things. Honestly, I don't expect mod_lua to see heavy use for content generation (will be happy for that to prove wrong), but python and ruby rule that roost right now, and external process proxying (fcgi, mod_proxy, mod_wsgi, whatever) all work great there. My personal target is everything *else* that you can hook :-) >
handling of security issues in alphas?
On Saturday 08 January 2011, s...@apache.org wrote: > Author: sf > Date: Sat Jan 8 14:29:12 2011 > New Revision: 1056713 > > URL: http://svn.apache.org/viewvc?rev=1056713&view=rev > Log: > Fix a bug in authz logic merging which caused > section->op == AUTHZ_LOGIC_AND > auth_result == AUTHZ_DENIED_NO_USER > child_result == AUTHZ_GRANTED > to return AUTHZ_GRANTED instead of AUTHZ_DENIED_NO_USER. > > While there, refactor the if blocks to make them a bit more > readable. > > Modified: > httpd/httpd/trunk/CHANGES > httpd/httpd/trunk/modules/aaa/mod_authz_core.c This was broken since r964156 / 2.3.8. Is there some agreed upon policy how to handle security issues that only affect alphas and/or betas? Do we need a CVE id? IMO: No for alphas, but maybe yes for betas?
Re: svn commit: r1056448 - /httpd/httpd/trunk/docs/manual/mod/mod_log_config.xml
On 07 Jan 2011, at 9:05 PM, William A. Rowe Jr. wrote: If caution is to be exercised for other reasons, such as losing data in the event of a crash, that's a separate issue, and should be handled separately. It should be used with caution. Instead of arguing, replace the caution. Or I'm happy to revert. I've got a better idea. Why not collaborate with the other people in this project instead of attempting to bully them with the threat of yet-another-veto? Use rpluem's email as an example of what to do, he suggested a potential alternative warning, and invited others to chime in with an improvement. This resulted in r1056693, and a resolution to the issue. Regards, Graham --
Re: svn commit: r1056448 - /httpd/httpd/trunk/docs/manual/mod/mod_log_config.xml
On 01/07/2011 08:05 PM, William A. Rowe Jr. wrote: > On 1/7/2011 12:49 PM, Graham Leggett wrote: >> If caution is to be exercised for other reasons, such as losing data in the >> event of a >> crash, that's a separate issue, and should be handled separately. > > It should be used with caution. Instead of arguing, replace the caution. > Or I'm happy to revert. > > How about This directive should be used with caution as a crash might cause loss of logging data. or something similar. Doc's wordsmithes please chime in :-). Regards Rüdiger
