RE: Windows Server 2008 Application Compatibility Lab Invitation
This is certainly something we can examine during the appcompat lab. There is still tools for building from the command line, (MSBuild, VCBuild), but they aren’t much like make... more like Ant. G -Original Message- From: Issac Goldstand [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 16, 2008 2:40 AM To: dev@httpd.apache.org Subject: Re: Windows Server 2008 Application Compatibility Lab Invitation This is probably all the way at the bottom of your priority list, but I figure it can't hurt to mention - what about a decent command line build solution; IIRC, one of the (very minor) reasons we're still with VC6 is the ability to create a Makefile, which recent VS suites no longer support... Issac William A. Rowe, Jr. wrote: > I'm planning to attend to address issues on several fronts, and I hear > some PHP folks will make it as well. It might be a really good chance > to start digging deeper into the interop issues with MSVCR runtimes, > so if there is a modperl dev or two who are interested, I'd love to > spend some of this time working on those specifics. > > Bill > > Garrett Serack wrote: >> Howdy, >> >> My name is Garrett Serack, and I am the Community Program Manager in >> the Open >> Source Software Labs here at Microsoft. >> >> I would like to extend an official invitation to the Apache Software >> Foundation >> to participate in the Microsoft Windows Server 2008 Compatibility >> Labs here >> in Redmond. The Compatibility lab is scheduled for >> >>Monday February 25 2008 through Wednesday February 28 2008. >> >> (the lab is actually booked thru Thurs the 29th, so an extra day is >> possible) >> >> WHAT IS IT? >> --- >> The Windows Server 2008 Application Compatibility Lab is an event >> where we >> invite companies to bring their applications into our lab, and have the >> opportunity to perform compatibility testing with Windows Server >> 2008. In >> addition to gaining insight into Windows Server 2008, this also includes >> unprecedented access to various product groups (developers, >> architects and PMs) >> inside of Microsoft, who can lend their assistance, give technical >> information >> and answer design questions you may have. >> >> Normally, we request companies send 3-4 attendees, and we usually >> have 3-4 >> companies in the lab in a given week. Given the ASF's size and >> breadth, we've >> reserved the entire lab for the week for the Apache Foundation, and >> we'd like >> to see somewhere in the range of 15-18 people from a wide variety of >> projects >> attend. >> >> >> WHO SHOULD COME? >> >> We would be very interested in having several people from the Tomcat, >> HTTPD and >> Axis groups attend. Other projects including APR, Apache C++ >> Standard Library >> project, Harmony, and Maven.NET also come to mind. Any project that >> is impacted >> by the release of Windows 2008, or is looking to solve >> Windows-specific project >> issues, may profit from this opportunity. >> >> We are interested in having each project who deals with Microsoft >> Windows >> compatibility or portability to bring small contingent of 1 or 2 >> developers to >> the table, so please chat within your own PMC or even your dev@ list >> first to >> determine who is most interested in attending this camp on behalf of >> your >> project. Space is constrained, and we'd like to ensure that specific >> attention >> can be given to projects that need it. >> >> >> WHAT'S THE COST? >> >> The cost of the event itself is being handled by our team (the Open >> Source >> Software Lab), all you have to do is actually get here. Some travel >> assistance >> by Microsoft will be available (hotel/airfare), *if* your employer can't >> pick up such costs. As my budget is limited, how much travel >> assistance we can >> provide is linked to how many need to avail themselves of it. If you >> don't >> need a subsidy, hotels can still be booked at MS's corp rate at most >> nearby, >> saving some money. >> >> >> WHAT IS THE PROCESS? >> >> To track interest, please register for this event in the subversion file >> >> >> https://svn.apache.org/repos/private/committers/hackathons/port25-08/attending.txt >> >> >> and send me an email with the following information: >> >>Full Name: >>Street Address: >>Phone Number: >>Email Address: >>ASF Projects Involved in: >>Travel Assistance Required: (full/part/none) >>Product Groups you wish to get access to: >>Any technical aspects you'd like to address: >> >> INSIGHT >> --- >> You might be interested in the "political" rational of why we value >> this chance >> to meet some of the ASF developers and help them work through Windows >> compatibility issues. You can see Sam Ramji's blog entry about why we >> asked >> Mozilla out: >> >> >> http://port25.technet.com/archive/2006/09/20/Why-I-invited-Mozilla.aspx >> >> Garrett Serack | Open Source Community Lead | Microsoft Corporation
Re: Is async the answer?
On Jan 28, 2008 9:57 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Olaf van der Spek wrote: > > > > I agree that FastCGI is the better technical solution, I'm just > > stating that neither the Apache documentation nor the PHP > > documentation seems to state that. Even worse, they hardly document > > the FastCGI way at all. > > FastCGI is a technically subpar way to execute trusted, valid PHP. Why? Isn't memory (and other resource) consumption a lot lower because you don't need a PHP 'engine' for every thread/process? Even valid PHP code can crash, given bugs in PHP itself. And I think tons of users sometimes run untrusted or invalid PHP. > People have always been under some preconception that it's good to run > untrusted code in-process within httpd, while numerous "vulnerability" > reports in the past (and many to appear over the future) all bear out > that it's a really stupid idea. Given that the alternatives (FastCGI) isn't well documented, I don't think that's strange. > FastCGI is also a so-so way to get around libraries which aren't thread- > safe, running worker or event mpm's. Of course, using the 21st century > equivalents of those libraries probably isn't a bad solution either. Olaf
Re: [PATCH] for bug 20832. Add double stat option
Akins, Brian wrote: For trunk, it's time finally to open the file earlier in the request cycle and use the fstat/file_info_get for the lifetime of the request. Thoughts? Maybe. I'm wondering how often we wind-up not using the file. I guess only when we redirect or something in fixups, maybe. Well, translate_name should be an OK thing to mess up the uri, filename etc. map_to_storage is supposed to associate the thing to a real resource, e.g. the file. So it seems that we should, in the dir_walk of map_to_storage, open() that ->filename and use its fstat(req->file) instead of doing the stat(), then open(). WDYT?
Re: Is async the answer?
On Jan 28, 2008, at 15:41, Akins, Brian wrote: On 1/28/08 3:29 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote: I agree that FastCGI is the better technical solution, I'm just stating that neither the Apache documentation nor the PHP documentation seems to state that. Even worse, they hardly document the FastCGI way at all. The only reason I know is because at Apachecon in Austin (?) the php and httpd guys kissed and made up and said a bunch of stuff about fastcgi in a presentation. Unfortunately, neither he (John Coggeshall) nor I followed up by doing anything useful to the documentation of either product to reflect that. :-( -- Speech is conveniently located midway between thought and action, where it often substitutes for both. John Andrew Holmes
Re: Is async the answer?
Olaf van der Spek wrote: I agree that FastCGI is the better technical solution, I'm just stating that neither the Apache documentation nor the PHP documentation seems to state that. Even worse, they hardly document the FastCGI way at all. FastCGI is a technically subpar way to execute trusted, valid PHP. So is the handler method, the most efficient is the httpd 2 filter method which should work fine since John and I spent a bunch of time on it. However, only a CGI sapi or FastCGI can compartmentalize your untrusted PHP applications. People have always been under some preconception that it's good to run untrusted code in-process within httpd, while numerous "vulnerability" reports in the past (and many to appear over the future) all bear out that it's a really stupid idea. FastCGI is also a so-so way to get around libraries which aren't thread- safe, running worker or event mpm's. Of course, using the 21st century equivalents of those libraries probably isn't a bad solution either. Bill
Re: Is async the answer?
On 1/28/08 3:29 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote: > I agree that FastCGI is the better technical solution, I'm just > stating that neither the Apache documentation nor the PHP > documentation seems to state that. Even worse, they hardly document > the FastCGI way at all. The only reason I know is because at Apachecon in Austin (?) the php and httpd guys kissed and made up and said a bunch of stuff about fastcgi in a presentation. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: [PATCH] for bug 20832. Add double stat option
On 1/28/08 12:35 PM, "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > AFAICT, this still does not resolve the problem, it simply picks up the > replacement of the file. Which is what I care about. > It does not address the root 80% of the problem when an open file is > then changed during the transmission. You get what you deserve if you do that, IMO. All of our publishing systems write to temp file, then rename to real name. > For trunk, it's time finally to open the file earlier in the request > cycle and use the fstat/file_info_get for the lifetime of the request. > Thoughts? Maybe. I'm wondering how often we wind-up not using the file. I guess only when we redirect or something in fixups, maybe. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Is async the answer?
On Jan 28, 2008 9:22 PM, Jim Jagielski <[EMAIL PROTECTED]> wrote: > >> http://www.php.net/manual/en/ > >> faq.installation.php#faq.installation.apache2 > > > > "If you feel you have to use a threaded MPM, look at a FastCGI > > configuration where PHP is running in its own memory space." > > > > Is that what is meant by "Fastcgi is the "recommended way of using php > > and httpd 2, AFAIK. Isn't it???"? > > A single line seems a bit odd for the recommended approach. > > > > Consider that, for many people, the main advantage of Apache2 over > Apache1 is the worker MPM. Also consider that a threaded MPM and > mod_php aren't a happy couple. If using prefork, mod_php works > just dandy... but for other reasons you'd likely want to > consider FastCGI anyway... I agree that FastCGI is the better technical solution, I'm just stating that neither the Apache documentation nor the PHP documentation seems to state that. Even worse, they hardly document the FastCGI way at all.
Re: Is async the answer?
On Jan 28, 2008, at 2:35 PM, Olaf van der Spek wrote: On Jan 28, 2008 8:04 PM, Eric Covener <[EMAIL PROTECTED]> wrote: On Jan 28, 2008 12:36 PM, Olaf van der Spek <[EMAIL PROTECTED]> wrote: On Jan 25, 2008 6:18 PM, Akins, Brian <[EMAIL PROTECTED]> wrote: On 1/24/08 3:14 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote: Working on making a FastCGI based setup the recommended approach instead of mod_php is probably more important then async. Actually, it's a prerequisite. Fastcgi is the "recommended way of using php and httpd 2, AFAIK. Isn't it??? Where can I read about that recommendation? I can't find it in the Apache or PHP manuals. mod_php appears to be *the* solution. http://www.php.net/manual/en/ faq.installation.php#faq.installation.apache2 "If you feel you have to use a threaded MPM, look at a FastCGI configuration where PHP is running in its own memory space." Is that what is meant by "Fastcgi is the "recommended way of using php and httpd 2, AFAIK. Isn't it???"? A single line seems a bit odd for the recommended approach. Consider that, for many people, the main advantage of Apache2 over Apache1 is the worker MPM. Also consider that a threaded MPM and mod_php aren't a happy couple. If using prefork, mod_php works just dandy... but for other reasons you'd likely want to consider FastCGI anyway...
Re: Is async the answer?
On Jan 28, 2008 8:04 PM, Eric Covener <[EMAIL PROTECTED]> wrote: > On Jan 28, 2008 12:36 PM, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > > On Jan 25, 2008 6:18 PM, Akins, Brian <[EMAIL PROTECTED]> wrote: > > > On 1/24/08 3:14 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Working on making a FastCGI based setup the recommended approach > > > > instead of mod_php is probably more important then async. Actually, > > > > it's a prerequisite. > > > > > > Fastcgi is the "recommended way of using php and httpd 2, AFAIK. Isn't > > > it??? > > > > Where can I read about that recommendation? > > I can't find it in the Apache or PHP manuals. > > mod_php appears to be *the* solution. > > http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2 "If you feel you have to use a threaded MPM, look at a FastCGI configuration where PHP is running in its own memory space." Is that what is meant by "Fastcgi is the "recommended way of using php and httpd 2, AFAIK. Isn't it???"? A single line seems a bit odd for the recommended approach.
Re: Is async the answer?
On Jan 28, 2008 12:36 PM, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > On Jan 25, 2008 6:18 PM, Akins, Brian <[EMAIL PROTECTED]> wrote: > > On 1/24/08 3:14 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote: > > > > > > > Working on making a FastCGI based setup the recommended approach > > > instead of mod_php is probably more important then async. Actually, > > > it's a prerequisite. > > > > Fastcgi is the "recommended way of using php and httpd 2, AFAIK. Isn't it??? > > Where can I read about that recommendation? > I can't find it in the Apache or PHP manuals. > mod_php appears to be *the* solution. http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2 -- Eric Covener [EMAIL PROTECTED]
Re: [PATCH] for bug 20832. Add double stat option
On Jan 28, 2008, at 12:35 PM, William A. Rowe, Jr. wrote: Akins, Brian wrote: Against trunk. Basically, has a new config "EnableDoubleStat" (I know, horrible name) off by default. If on, will use apr_file_info_get on open file handle. Based on patch in thread: http://issues.apache.org/bugzilla/show_bug.cgi?id=43386 Doesn't apply cleanly against 2.2.8. AFAICT, this still does not resolve the problem, it simply picks up the replacement of the file. It does not address the root 80% of the problem when an open file is then changed during the transmission. If crucial, then we lock it... Doesn't it make more sense to re-fstat at the end of the transmission, if the expected file sie has again changed, and gracefully finish the request best-we-can? I'm strongly -1 on leaving this solution for trunk, but +/- 0 for backporting this approach to 2.2/2.0 (call it SlowerStatDoubleCheck :-?) since we can't change fundamentally change the API here. For trunk, it's time finally to open the file earlier in the request cycle and use the fstat/file_info_get for the lifetime of the request. Thoughts? Bill
Re: Is async the answer?
On Jan 25, 2008 6:18 PM, Akins, Brian <[EMAIL PROTECTED]> wrote: > On 1/24/08 3:14 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote: > > > > Working on making a FastCGI based setup the recommended approach > > instead of mod_php is probably more important then async. Actually, > > it's a prerequisite. > > Fastcgi is the "recommended way of using php and httpd 2, AFAIK. Isn't it??? Where can I read about that recommendation? I can't find it in the Apache or PHP manuals. mod_php appears to be *the* solution. > > What about a hybrid approach? > > Async for network IO and other stuff that doesn't require sync calls, > > worker threads for other parts? > > That's kind of what I was thinking after Apachecon US this year. I won't > speak for others, but it seemed reasonable to most. However, after doing > several real world tests, I just don't honestly see that async will be a > huge improvement. Please prove me wrong with real world results. I'd be > more than happy to be wrong on this, really. I don't have real world test results. Have you tested the 30k scenario with an async web server? And do all platforms have such cheap threading as your test platform? > To be honest, I don't have strong feelings either way. I was surprised by > my results. I, now, think that completely rewriting the core to be async > *may be* a "waste of resources." If it fits nicely into some ideas on > reengineering buckets and brigades (ala serf stuff), and does not actually > decrease overall performance, then by all means do it. > > Remember, I'm partially playing devil's advocate as well... I noticed. ;)
Re: [PATCH] for bug 20832. Add double stat option
Akins, Brian wrote: Against trunk. Basically, has a new config "EnableDoubleStat" (I know, horrible name) off by default. If on, will use apr_file_info_get on open file handle. Based on patch in thread: http://issues.apache.org/bugzilla/show_bug.cgi?id=43386 Doesn't apply cleanly against 2.2.8. AFAICT, this still does not resolve the problem, it simply picks up the replacement of the file. It does not address the root 80% of the problem when an open file is then changed during the transmission. Doesn't it make more sense to re-fstat at the end of the transmission, if the expected file sie has again changed, and gracefully finish the request best-we-can? I'm strongly -1 on leaving this solution for trunk, but +/- 0 for backporting this approach to 2.2/2.0 (call it SlowerStatDoubleCheck :-?) since we can't change fundamentally change the API here. For trunk, it's time finally to open the file earlier in the request cycle and use the fstat/file_info_get for the lifetime of the request. Thoughts? Bill
Re: [PATCH] for bug 20832. Add double stat option
Me like for trunk... if approved there, I'll backport. Of course, it requires mmn bump. On Jan 28, 2008, at 9:41 AM, Akins, Brian wrote: Against trunk. Basically, has a new config "EnableDoubleStat" (I know, horrible name) off by default. If on, will use apr_file_info_get on open file handle. Based on patch in thread: http://issues.apache.org/bugzilla/show_bug.cgi?id=43386 Doesn't apply cleanly against 2.2.8. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: My hacked mod_xsendfile
On Jan 25, 2008, at 3:40 PM, Akins, Brian wrote: On 1/25/08 3:33 PM, "André Malo" <[EMAIL PROTECTED]> wrote: I'm not sure if a filter is semantically the right place. IMHO that smells a bit problematic. It might be better to I'd rather hack that into a function similar to ap_internal_redirect and let it call explicitly. That way you'd need to hack a recognition per backend (but the code is mostly there anyway), on the other hand you could enable and disable it per backend. A filter was just convenient. It needs to be generic as possible so that, a) people will use it, b) noone has to edit their backend much to support it. Agreed that impl via filter seems "better"
Re: Huge httpd-process
On 01/28/2008 04:26 PM, Marten Lehmann wrote: > Hello, > >>> We are currently using httpd-2.2.4. Hoe comes, that httpd processes >>> can get that huge? >> >> Martin, may I recommend that you send such support questions to one of >> the >> our user mailing lists instead of the developer list. >> >> http://httpd.apache.org/userslist.html (English) >> http://httpd.apache.org/usersdelist.html (German) > > I was doing so, but noone has answered. And the request us very > technical and not a configuration issue, so I don't think that common > users may help me. Maybe it is a bug since httpd processes should never If you think this is a bug, please open a bug in bugzilla. Adding you configuration to the bug could be also helpful. > consume that much memory (we are not using mod_php, mod_perl or anything > like that). Do you use any other third party modules? Regards Rüdiger
Re: Huge httpd-process
Hello, We are currently using httpd-2.2.4. Hoe comes, that httpd processes can get that huge? Martin, may I recommend that you send such support questions to one of the our user mailing lists instead of the developer list. http://httpd.apache.org/userslist.html (English) http://httpd.apache.org/usersdelist.html (German) I was doing so, but noone has answered. And the request us very technical and not a configuration issue, so I don't think that common users may help me. Maybe it is a bug since httpd processes should never consume that much memory (we are not using mod_php, mod_perl or anything like that). Regards Marten
Re: Huge httpd-process
Marten Lehmann wrote: > We are currently using httpd-2.2.4. Hoe comes, that httpd processes can > get that huge? Martin, may I recommend that you send such support questions to one of the our user mailing lists instead of the developer list. http://httpd.apache.org/userslist.html (English) http://httpd.apache.org/usersdelist.html (German) Best Regards -- Lars Eilebrecht [EMAIL PROTECTED]
[PATCH] for bug 20832. Add double stat option
Against trunk. Basically, has a new config "EnableDoubleStat" (I know, horrible name) off by default. If on, will use apr_file_info_get on open file handle. Based on patch in thread: http://issues.apache.org/bugzilla/show_bug.cgi?id=43386 Doesn't apply cleanly against 2.2.8. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies double-stat.diff Description: Binary data
Huge httpd-process
Hello, using "top", I noticed this output: top - 08:48:40 up 24 days, 17:21, 1 user, load average: 173.78, 113.81, 52.58 Tasks: 449 total, 47 running, 397 sleeping, 0 stopped, 5 zombie Cpu(s): 5.2% us, 56.6% sy, 0.4% ni, 0.0% id, 37.5% wa, 0.0% hi, 0.2% si Mem: 2056328k total, 2038468k used,17860k free, 3216k buffers Swap: 2040244k total, 2040244k used,0k free,29344k cached PID USER PR NI %CPUTIME+ %MEM VIRT RES SHR S COMMAND 68 root 16 0 49 16:59.70 0.0 000 R kswapd0 17689 nobody16 0 12 1:00.98 65.2 3665m 1.3g 1832 D httpd 21497 u1175416 04 0:00.16 0.4 63240 8072 4604 D php 21064 u1273216 03 0:00.30 0.5 109m 9628 4652 D php 18761 nobody16 03 0:00.36 0.1 38808 2124 1632 S httpd 21068 u1207218 03 0:00.31 0.8 72212 16m 4616 R php 21093 nobody16 03 0:00.12 0.1 38612 1940 1444 S httpd In our configuration, httpd runs as user nobody to deliver static content. We have SSL and non-SSL hosts (mostly). As soon as perl or php scripts are started, a cgiwrapper is being used, so the processes have a different user id and another command name (php in this case). So I'm really wondering, why there is a httpd process which uses 65% of the memory. As you can see in the load average line, the process is getting even greater. This occurs every now and then. And there are following effects of this: - swapd is used to get more memory which slows down the system - sometimes the httpd-process us killed automatically (or at least disappears at some point and the system goes back to usual load, or: - httpd-process is consistently consuming more and more memory, even swapd can't help, the whole system crashes. Within our cgiwrapper, we have memory limits, But since this all is happens within apache, we cannot set any limits. We are currently using httpd-2.2.4. Hoe comes, that httpd processes can get that huge? Regards Marten
Re: [VOTE] Apache HTTP Server 1.3.41, 2.0.63 and 2.2.8
On 14 Jan 2008, at 22:57, Nick Kew wrote: On Mon, 14 Jan 2008 11:58:53 -0500 Jim Jagielski <[EMAIL PROTECTED]> wrote: I am keeping voting open, simply because we don't have a lot of votes currently... PMC members especially, please download, test and vote. 2.2.8: Linux clear +1, MacOSX tentative +1 which MacOSX? Tried compiling on 10.5.1 but the result does not work. Apart from the long standing problem of a missing -lz when deflate is enabled (-lz is added to the required libs according to configure, but must be given by hand in two instances for the build process to succeed), the resulting httpd fails when loading mod_ssl. The _ssl_cmd_SSLCACertificateFile symbol is missing and this seems to stem from some ranlib problems (symbols not exported). I used the apr included in 2.2.8. No success with the one that comes with 10.5.1 either. I am trying now to compile apr from the latest 1.2.12. thanks Giuliano
Re: My hacked mod_xsendfile
On 1/28/08 4:35 AM, "Ivan Ristic" <[EMAIL PROTECTED]> wrote: The FastCGI process is likely to be running under a different > account, but here we have a facility that allows that other process to > use the privileges of the Apache user to fetch a file. I can see how > this feature could easily find its way to the list of small tricks > that can be used to compromise a web server installation, one step at > a time. Perhaps. Most of out fastcgi stuff gets executed by httpd, so it has the same privileges. Also php under fastgci has access to everything completely outside httpd, for example. I guess if we choose to include support, but the appropriate security warnings. Also, this approach will use all the normal httpd file access controls rather than just grabbing it "directly." It is also a "first draft" and I'm sure needs work, but I'd like us to push to get xsendfile into core. It's already Apache license, if that helps. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: High security
On Jan 25, 2008 1:30 PM, Nick Kew <[EMAIL PROTECTED]> wrote: > > ... > > > A > > compromise might be to create a chroot hook and allow module > > developers to use it. This would shift the support burden somewhat > > from the core Apache team to those willing to engage the users > > providing support. > > Isn't that basically the status quo (mod_security presumably hooks it > in at post_config?) In ModSecurity I had to use one of the available hooks to execute the chroot call. As Torsten mentions, that might be a much better place to do it. > > Personally, I don't really have a need for the internal chroot feature > > ever since I discovered the makejail utility (part of Debian, and > > maybe other systems), which worked really well for me. On the other > > hand, I am interested in getting Apache to drop certain capabilities > > (where supported) at startup. I plan to look into it eventually. > > Can we expect your contributions to the apache core code in the > not-too-distant? Possibly... Maybe I should aim to start with something simpler; for example, by proposing the suexec chroot patch I have lying around somewhere. > -- > Nick Kew > > Application Development with Apache - the Apache Modules Book > http://www.apachetutor.org/ > -- Ivan Ristic
Re: My hacked mod_xsendfile
On Jan 25, 2008 7:55 PM, Akins, Brian <[EMAIL PROTECTED]> wrote: > I started to play with xsendfile more. I noticed the mod_xsendfile floating > around tried to basically replace what the default handler does very well. > > Basically, my version does a subrequest for the file. This allows things > like "Deny from all", etc, to work. This should be more secure, ie, if you > set your deny's correctly, you can't "X-Sendfile: /etc/passwd". All in all, > it seems more "httpd"-like, to me. I am not very familiar with X-Sendfile (as in: I read about it but never used it), but it sounds like it's breaking the FastCGI security model. The FastCGI process is likely to be running under a different account, but here we have a facility that allows that other process to use the privileges of the Apache user to fetch a file. I can see how this feature could easily find its way to the list of small tricks that can be used to compromise a web server installation, one step at a time. > It is very rough. I do not understand brigades enough to know why it is > chunking every reply in my tests. I have tested with just a normal cgi > setting the header. > > Not well tested. I'd like to see us work toward getting X-sendfile into the > normal httpd distribution (along with mod_fcgid...) > > > -- > Brian Akins > Chief Operations Engineer > Turner Digital Media Technologies > > -- Ivan Ristic
