Re: 2.2.9
Nick Kew wrote: If the docs are not clear to you, I think that demonstrates the need for further review. What is unclear about ¨The underlying library doesn't support prepared statements, so the driver emulates them, and the untrusted input is merged into the SQL statement.¨ I guess my point is, why do we enable this without requiring the user to explicitly choose this client? Caveat emptor; it shouldn't happen without user intervention. Bill
Re: 2.2.9
On Tue, 2008-05-06 at 23:56, William A. Rowe, Jr. wrote: > Or more specifically, could you elaborate on the dbd changes within > apr 1.3.x that need additional review? Why is this driver not > correctly dodged? > > Bill If the docs are not clear to you, I think that demonstrates the need for further review. What is unclear about ¨The underlying library doesn't support prepared statements, so the driver emulates them, and the untrusted input is merged into the SQL statement.¨ ? -- Nick Kew
Re: 2.2.9
Nick Kew wrote: The target audience for APR is tech-savvy: developers and integrators. HTTPD has a larger and more mixed audience. I'd say that puts on us a greater burden of care, including crucially a proper review of changes in 1.3, before bundling it in a release version of HTTPD. I don't believe that our /not/ shipping with apr-1.3 saves anyone any grief. If apr-1.3.x branch is flawed, it must be fixed, and then 1.3.0 released. Why ship on 1.2.x, only to have a subset of users deploy against the released 1.3.0 and report errant behavior? I would much rather know from user experience that 1.3.0 did not suit them, and why, and direct them that they can manually configure against 1.2.x as mentioned earlier in this thread. As an example of what I'm concerned about, I'd point to the serious security issue I recently documented in mod_dbd (trunk version of docs). APR-UTIL 1.2 excludes the dangerous driver; 1.3 includes it. Can we enumerate other potentially-serious issues? Or more specifically, could you elaborate on the dbd changes within apr 1.3.x that need additional review? Why is this driver not correctly dodged? Bill
Re: 2.2.9
On Tue, 6 May 2008 09:50:41 -0400 Jim Jagielski <[EMAIL PROTECTED]> wrote: > 2. Consensus on whether we ship with APR 1.2.x or 1.3.x... >My pref would be 1.3. -1. The target audience for APR is tech-savvy: developers and integrators. HTTPD has a larger and more mixed audience. I'd say that puts on us a greater burden of care, including crucially a proper review of changes in 1.3, before bundling it in a release version of HTTPD. As an example of what I'm concerned about, I'd point to the serious security issue I recently documented in mod_dbd (trunk version of docs). APR-UTIL 1.2 excludes the dangerous driver; 1.3 includes it. Can we enumerate other potentially-serious issues? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: sendfile in darwin
I should have some cycles to dig deeper on this tomorrow...
Re: svn commit: r653856 - /httpd/httpd/trunk/docs/manual/mod/core.xml
On Tue, May 6, 2008 at 1:57 PM, <[EMAIL PROTECTED]> wrote: > +Note > + This directive will be ignored in a name-based virtual host > context. > + That should just be an ordinary with no type=. warning is for really-important stuff like security problems. (Obviously we should have called it something like "important", rather than "warning", since you aren't the first to use it that way.) Joshua.
Re: sendfile in darwin
On May 6, 2008, at 1:53 PM, William A. Rowe, Jr. wrote: Jim Jagielski wrote: Will see how the latest 1.2.x does... Uhm - 1.2.x deliberately disables sendfile detection on Darwin. Yep, and so the test runs cleanly (confirmed)...
Re: sendfile in darwin
Jim Jagielski wrote: Will see how the latest 1.2.x does... Uhm - 1.2.x deliberately disables sendfile detection on Darwin.
sendfile in darwin
Hmmm at least in apr-1.3.0 (HEAD), sendfile in Darwin still seems broken... getting: [Tue May 06 13:35:26 2008] [crit] [Tue May 06 13:35:26 2008] file core_filters.c, line 391, assertion "total_bytes_left > 0 && tmplen > 0" failed from the test framework for httpd: t/apache/getfile...ok 1/144# Failed test 143 in t/apache/ getfile.t at line 23 fail #143 t/apache/getfile...NOK 143# Failed test 144 in t/apache/ getfile.t at line 23 fail #144 t/apache/getfile...FAILED tests 143-144 Failed 2/144 tests, 98.61% okay Will see how the latest 1.2.x does...
Re: High security
On May 6, 2008, at 8:10 AM, Nick Gearls wrote: Can you tell me where to find the XML doc file ? It's not obvious from the site :-( Check out the httpd trunk: svn co http://svn.apache.org/repos/asf/httpd/httpd/trunk httpd and the XML file we're talking about will be httpd/docs/manual/mod/mpm_common.xml S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: 2.2.9
On May 6, 2008, at 7:36 AM, Plüm, Rüdiger, VF-Group wrote: 2. Consensus on whether we ship with APR 1.2.x or 1.3.x... My pref would be 1.3. Ship with 1.3, but do not make it depend on 1.3 yet. This makes it easy to swap in 1.2.x again if it turns out that there is something nasty in 1.3. We can can make it dependant on 1.3 in 2.2.10 or 2.2.11 depending on our experience. +1 S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: 2.2.9
On Tue, May 6, 2008 at 4:36 PM, Plüm, Rüdiger, VF-Group < [EMAIL PROTECTED]> wrote: > > > > -Ursprüngliche Nachricht- > > Von: Jim Jagielski > > Gesendet: Dienstag, 6. Mai 2008 15:51 > > An: dev@httpd.apache.org > > Betreff: Re: 2.2.9 > > > > I'm back from a few days away and offline, and like to get > > the momentum for 2.2.9 back up. > > > > 2 main things: > > > > 1. There are a number of backport proposals looking > >for and waiting for a 3rd +1... if you have time > >to look/review/vote, that would be good. > > > > 2. Consensus on whether we ship with APR 1.2.x or 1.3.x... > >My pref would be 1.3. > > Ship with 1.3, but do not make it depend on 1.3 yet. This makes it > easy to swap in 1.2.x again if it turns out that there is something > nasty in 1.3. We can can make it dependant on 1.3 in 2.2.10 or 2.2.11 > depending on our experience. > > Regards > > Rüdiger > I really like this proposal (my non counting +1 on this) -- ~Jorge
Re: High security
Can you tell me where to find the XML doc file ? It's not obvious from the site :-( Thanks, Nick Dirk-Willem van Gulik wrote: On May 6, 2008, at 4:12 PM, Nick Gearls wrote: If there's a chance to add it, I'm ready to write the doc patch Lets get that in there - and then lets (or I'll) backport it - so it goes into the next release. Dirk-Willem van Gulik wrote: On May 6, 2008, at 3:27 PM, Nick Gearls wrote: Just a little adding: by adding "LoadFile libgcc_s.so.1" in httpd.conf, I don't have any more file in the chroot (except "htdocs" if not in pure proxy mode). Is there a patch for the docs as well ? Including above trick ? Nick Gearls wrote: I'm running the patch for one week on a production server, and it works perfectly (http://svn.apache.org/viewvc?view=rev&revision=611483). When using Apache as a reverse proxy, the chroot environment is totally empty (except libgcc_s.so.1). Could we include this in next build ? As it is very limited (basically 3 basic function calls plus the logging), it is trivial to review. +1 Regards, Nick [... discussion about chroot effectiveness and letting the final choice to the user to use it or not ...] Dw.
Re: High security
On May 6, 2008, at 5:03 PM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Dirk-Willem van Gulik Gesendet: Dienstag, 6. Mai 2008 17:00 An: dev@httpd.apache.org Betreff: Re: High security On May 6, 2008, at 4:12 PM, Nick Gearls wrote: If there's a chance to add it, I'm ready to write the doc patch I did below a while ago. May be useful as a start. There is already a documentation in trunk for this: http://svn.apache.org/viewvc?view=rev&revision=639005 Aye - I edited on top of that version. Dw.
re: High security
> -Ursprüngliche Nachricht- > Von: Dirk-Willem van Gulik > Gesendet: Dienstag, 6. Mai 2008 17:00 > An: dev@httpd.apache.org > Betreff: Re: High security > > > On May 6, 2008, at 4:12 PM, Nick Gearls wrote: > > If there's a chance to add it, I'm ready to write the doc patch > > > I did below a while ago. May be useful as a start. There is already a documentation in trunk for this: http://svn.apache.org/viewvc?view=rev&revision=639005 Regards Rüdiger
Re: High security
On May 6, 2008, at 4:12 PM, Nick Gearls wrote: If there's a chance to add it, I'm ready to write the doc patch I did below a while ago. May be useful as a start. Dw Index: mpm_common.xml === --- mpm_common.xml (revision 653793) +++ mpm_common.xml (working copy) @@ -1039,14 +1039,26 @@ preforkworker -This directive, available in httpd 2.2.9(?) and later, tells the +This directive, available in httpd 2.2.9(?) and later on unix, tells the server to chroot(8) to the specified directory after -startup, but before accepting requests over the 'net. -Note that running the server under chroot is not simple, -and requires additional setup, particularly if you are running -scripts such as CGI or PHP. Please make sure you are properly -familiar with the operation of chroot before attempting to use -this feature. +startup and logfile-opening, but before accepting requests over the 'net. +Security + Note that running the server under chroot is not simple, + and requires additional setup, particularly if you are running + scripts such as CGI or PHP. Please make sure you are properly + familiar with the operation of chroot before attempting to use + this feature. + +In conjunction the LoadFiledirective> +directive which can be used to load dependencies (for example a library such as +libgcc_s.so.1) prior to the chroot - thus allowing +a nearly empty chroot environment. See the +howto on chroot for more information. + for an example. +Note + This directive is only available on unix platforms which + support chroot(2). +
Re: High security
> -Ursprüngliche Nachricht- > Von: Dirk-Willem van Gulik > Gesendet: Dienstag, 6. Mai 2008 16:20 > An: dev@httpd.apache.org > Betreff: Re: High security > > > On May 6, 2008, at 4:12 PM, Nick Gearls wrote: > > If there's a chance to add it, I'm ready to write the doc patch > > Lets get that in there - and then lets (or I'll) backport it - so it > goes into the next release. There is already a backport proposal in the STATUS file: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?revision=653778&view=markup Regards Rüdiger
Re: 2.2.9
> -Ursprüngliche Nachricht- > Von: Jim Jagielski > Gesendet: Dienstag, 6. Mai 2008 15:51 > An: dev@httpd.apache.org > Betreff: Re: 2.2.9 > > I'm back from a few days away and offline, and like to get > the momentum for 2.2.9 back up. > > 2 main things: > > 1. There are a number of backport proposals looking >for and waiting for a 3rd +1... if you have time >to look/review/vote, that would be good. > > 2. Consensus on whether we ship with APR 1.2.x or 1.3.x... >My pref would be 1.3. Ship with 1.3, but do not make it depend on 1.3 yet. This makes it easy to swap in 1.2.x again if it turns out that there is something nasty in 1.3. We can can make it dependant on 1.3 in 2.2.10 or 2.2.11 depending on our experience. Regards Rüdiger
Re: High security
On May 6, 2008, at 4:12 PM, Nick Gearls wrote: If there's a chance to add it, I'm ready to write the doc patch Lets get that in there - and then lets (or I'll) backport it - so it goes into the next release. Dirk-Willem van Gulik wrote: On May 6, 2008, at 3:27 PM, Nick Gearls wrote: Just a little adding: by adding "LoadFile libgcc_s.so.1" in httpd.conf, I don't have any more file in the chroot (except "htdocs" if not in pure proxy mode). Is there a patch for the docs as well ? Including above trick ? Nick Gearls wrote: I'm running the patch for one week on a production server, and it works perfectly (http://svn.apache.org/viewvc?view=rev&revision=611483 ). When using Apache as a reverse proxy, the chroot environment is totally empty (except libgcc_s.so.1). Could we include this in next build ? As it is very limited (basically 3 basic function calls plus the logging), it is trivial to review. +1 Regards, Nick [... discussion about chroot effectiveness and letting the final choice to the user to use it or not ...] Dw.
Re: High security
If there's a chance to add it, I'm ready to write the doc patch Nick Dirk-Willem van Gulik wrote: On May 6, 2008, at 3:27 PM, Nick Gearls wrote: Just a little adding: by adding "LoadFile libgcc_s.so.1" in httpd.conf, I don't have any more file in the chroot (except "htdocs" if not in pure proxy mode). Is there a patch for the docs as well ? Including above trick ? Nick Gearls wrote: I'm running the patch for one week on a production server, and it works perfectly (http://svn.apache.org/viewvc?view=rev&revision=611483). When using Apache as a reverse proxy, the chroot environment is totally empty (except libgcc_s.so.1). Could we include this in next build ? As it is very limited (basically 3 basic function calls plus the logging), it is trivial to review. +1 Regards, Nick [... discussion about chroot effectiveness and letting the final choice to the user to use it or not ...]
Re: [PATCH] DTrace probes patch.
On May 6, 2008, at 8:21 AM, Dirk-Willem van Gulik wrote: On May 5, 2008, at 9:27 PM, Theo Schlossnagle wrote: The patch has some nastiness to it that I'm sure people would want to strategize on cleaning up. The main issue being that Apache is constructed from a bunch of static apr/libtool built libraries. DTrace doesn't work on archives. So, I've got some bloody knuckles from bending the build system to keep things as normal ELF objects. I had a first good step... and then a red herring issue that I worked through with the DTrace team led me to a much less-elegant way of building. I could revert to the original process (ld -r -o the objects into library-esque packages) as DTrace can work on those. The probes are neatly defined and placed, but the patches to the build system are gruesome. The apr-util patch to the apr_hooks.h is simple and affords some nice probability for future probe uses. Docs on these probes are available here: https://labs.omniti.com/trac/project-dtrace/wiki/ Applications#Apache2.2.x I'm not on this list -- Cc me on pertinent responses please. Works lovely on Solaris with the normal/real libtool - but not with Justin's. On MacOSX I think there is something wrong with the linker. Either MacOS does not need the extra -G or -h is enough on all platforms. What is the downside/penalty for making this a default ? Or should this always be an optional thing - set at ./configure time ? I see no issues with making this the default and having a --disable- dtrace. I can see a reason that someone might wish to turn them off -- thought that someone isn't me. Note, that to get all the apr_hooks linked up (which allows timing hook call-times and classifying system calls by hook name and phase) we need to patch apr_hooks.h. The patch for that changes flow slightly (but not outcome) and has no cost when disabled. Also, the way I wrote that was to use another define to turn that on "APR_DTRACE_PROVIDER". So, anyone using apr-util for hooks can enable or disable probes on those hooks with that define. -- Theo Schlossnagle Esoteric Curio -- http://lethargy.org/ OmniTI Computer Consulting, Inc. -- http://omniti.com/
Re: 2.2.9
I'm back from a few days away and offline, and like to get the momentum for 2.2.9 back up. 2 main things: 1. There are a number of backport proposals looking for and waiting for a 3rd +1... if you have time to look/review/vote, that would be good. 2. Consensus on whether we ship with APR 1.2.x or 1.3.x... My pref would be 1.3.
Re: High security
On May 6, 2008, at 3:27 PM, Nick Gearls wrote: Just a little adding: by adding "LoadFile libgcc_s.so.1" in httpd.conf, I don't have any more file in the chroot (except "htdocs" if not in pure proxy mode). Is there a patch for the docs as well ? Including above trick ? Nick Gearls wrote: I'm running the patch for one week on a production server, and it works perfectly (http://svn.apache.org/viewvc?view=rev&revision=611483 ). When using Apache as a reverse proxy, the chroot environment is totally empty (except libgcc_s.so.1). Could we include this in next build ? As it is very limited (basically 3 basic function calls plus the logging), it is trivial to review. +1 Regards, Nick [... discussion about chroot effectiveness and letting the final choice to the user to use it or not ...]
Re: High security
Just a little adding: by adding "LoadFile libgcc_s.so.1" in httpd.conf, I don't have any more file in the chroot (except "htdocs" if not in pure proxy mode). This feature is really great ! Any reason to not include it ? Regards, Nick Nick Gearls wrote: I'm running the patch for one week on a production server, and it works perfectly (http://svn.apache.org/viewvc?view=rev&revision=611483). When using Apache as a reverse proxy, the chroot environment is totally empty (except libgcc_s.so.1). Could we include this in next build ? As it is very limited (basically 3 basic function calls plus the logging), it is trivial to review. +1 Regards, Nick [... discussion about chroot effectiveness and letting the final choice to the user to use it or not ...]
Re: [PATCH] DTrace probes patch.
On Tue, May 06, 2008 at 02:21:53PM +0200, Dirk-Willem van Gulik wrote: > What is the downside/penalty for making this a default ? Or should this > always be an optional thing - set at ./configure time ? > The whole point of dtrace is that there really shouldn't be a penalty while no probes are being used. I'd prefer to see it on by default where available, but still leaving an option to explicitly disable it. vh Mads Toftum -- http://soulfood.dk
Re: [PATCH] DTrace probes patch.
On May 5, 2008, at 9:27 PM, Theo Schlossnagle wrote: The patch has some nastiness to it that I'm sure people would want to strategize on cleaning up. The main issue being that Apache is constructed from a bunch of static apr/libtool built libraries. DTrace doesn't work on archives. So, I've got some bloody knuckles from bending the build system to keep things as normal ELF objects. I had a first good step... and then a red herring issue that I worked through with the DTrace team led me to a much less-elegant way of building. I could revert to the original process (ld -r -o the objects into library-esque packages) as DTrace can work on those. The probes are neatly defined and placed, but the patches to the build system are gruesome. The apr-util patch to the apr_hooks.h is simple and affords some nice probability for future probe uses. Docs on these probes are available here: https://labs.omniti.com/trac/project-dtrace/wiki/ Applications#Apache2.2.x I'm not on this list -- Cc me on pertinent responses please. Works lovely on Solaris with the normal/real libtool - but not with Justin's. On MacOSX I think there is something wrong with the linker. Either MacOS does not need the extra -G or -h is enough on all platforms. What is the downside/penalty for making this a default ? Or should this always be an optional thing - set at ./configure time ? Dw.
