Apache HTTP Server Usage Survey Results

This post ran originally on blogs.apache.org/httpd.

Wouldn’t it be nice if you had an idea of how people use the software that you write? I wanted to have an idea how the Apache HTTP Server is being used, and which features users consider important. So, I set up a short online survey of eight questions and sent a link to it to the HTTP Server project user and developer mailing lists. Over the next week and a half, I got 134 responses. Here are the survey results in shiny pie charts with witty interpretation.
Continue reading

ApacheCon Meetup: Whither HTTPD?

ApacheCon North America 2010You can now suggest Meetup topics for the evenings of ApacheCon. I’m not sure what a Meetup is in this context: perhaps it’s a little like a BOF. Anyway, I went ahead and registered a Meetup with the following topic:

HTTP Server 3.0: Who Needs It? Who Wants It? Who will Write It?
Whither httpd? Does our User Community need a quantum shift that would require a major new version number? Does our Developer have this need and would/could/are they in a position to start major new development on the project? Will 2.x serve us until the end of time?

This topic is partially inspired by the Keynote session Roy Fielding presented in Amsterdam in 2008 on Apache 3.0: two-and-a-half years later seems like a good time to take stock. If you want to talk about this, come to ApacheCon and join the Meetup. Did I mention that rates go up after Friday, October 8?

File System Permissions for Apache

I don’t spend a lot of time on The Apache HTTP Server Users mailing list, but a discussion sprang up there this week on which I think I should share my response. The issue was why the server in question did not have permission to show a particular file. The initial response was “just chown your document root to the Apache user” and, when pointed out that this introduced security issues,

Oh man an experienced sys admin told me to do it that way.
Please tell me what is wrong in this and where is this documented on Apache 
I want to read.

Here is my response reproduced: read on.

The Apache HTTP Server needs read access to its configuration files and the files it serves. In and of itself, the server does not need write access anywhere on the system: even its log files are opened for write when the server is still root, and the open file descriptors passed to the child processes which change their user id to the lesser privileged user.

Read access only. The web server user should not own, or be able to write to, its configuration files or content.

Content, other than CGI scripts, generally does not need Execute permissions. Even PHP files that are interpreted by the server do not need to be Executable.

Certain applications, especially publishing platforms and Content Management Systems that you manage and populate through the web server itself using a browser, require that certain directories on the system be made writable by the web server user. You can do this by changing the owner of the directory to that user (usually www but ymmv), or by making the directory group-writable and changing the group to the group as which Apache runs.

Making directories writable by the web server should be done only with care and consideration. The usual threat model is that someone manages to upload (for instance) a PHP script of their own making into the document root, and simply executes that by accessing it through a browser. Now someone is executing code on your machine. Google for ‘r57’ for an example of what such code can do.

If a web app needs writable directories, it’s often better to have those outside the DocumentRoot: that way the uploads can’t be accessed from the outside through a direct URL. Some applications (WordPress for instance) support this, others do not.

In many cases, writable directories are not strictly necessary even though the web app might like them: rather than upload plugins (which contain code that gets executed or interpreted, yech!) through the web browser, upload them through ssh and manually unpack them on the server. The CMS Joomla! likes to write its configuration file to the Document Root on initial install (which promptly becomes a popular attack target) but if it can’t write to the Document Root, it will output the config to the browser to the user can manually upload it.

The Apache Documentation will merely tell you to make the server installation root-owned. The HTTP Server Documentation does not cover third party applications like WordPress or Joomla!, so it will not discuss their need to have some directories writable. I hope the above makes the picture a little more complete.

ApacheCon NA 2010 HTTP Server Track Call for Participation

ApacheCon North America 2010 will be held 1-5 November 2010, at the Westin Peachtree in Atlanta, Georgia, USA.

The official conference, trainings and expo of the Apache Software Foundation (ASF) will run to Atlanta this November, with dozens of sessions on Servers, Cloud Computing, Search NoSQL, Incubating projects, innovations, emerging technologies, and more.

ApacheCon would not be complete without a track dedicated to the project that started it all, the Apache HTTP Server. The Project Management Committee (PMC) are currently planning our own technical track for ApacheCon. We are solliciting 50-minute presentations for our conference track, to fill one day at the conference.

Topics of interest include:

  • Case studies on deployment of the Apache HTTP Server within your organization
  • How-to sessions on working with certain aspects of the Apache HTTP Server technology
  • What’s New? sessions on new features of recent and upcoming versions of the Apache HTTP Server
  • Sessions discussing third-party extensions to the Apache HTTP Server
  • Security topics surrounding the Apache HTTP Server
  • Performance and scalability of Apache HTTP Server deployment
  • Cool things we all should know the Apache HTTP Server can do
  • How you solved particularly gnarly problems deploying the Apache HTTP Server

Submissions are open to anyone with relevant expertise: ASF affiliation is not required to present at, attend, or otherwise participate in ApacheCon.

Please keep in mind that whilst we are encourage submissions that the highlight the use of specific Apache solutions, we are unable to accept marketing/commercially-oriented presentations.

All accepted speakers (not co-presenters) qualify for general conference admission and a minimum of two nights lodging at the conference hotel. Additional hotel nights and travel assistance are possible, depending on the number of presentations given and type of assistance needed.

To submit a presentation proposal, please edit the Wiki page and add your proposal, including:

  1. Your full name, title and organization
  2. Contact information, including your e-mail address. Feel free to obfuscate if you think that this will make a difference in your SPAM load
  3. The name of your proposed session (keep your title simple and relevant to the topic)
  4. A 75-200 word overview of your presentation
  5. A 100-200 word speaker bio that includes prior conference speaking or related experience

You will find an empty table template at the bottom of the page. Please copy this and fill it in.

Please mail any quesions regarding proposal submissions to pmc at httpd.apache.org.

To be considered, proposals must be received by Sunday, April 4nd, 2010, at 23:59:59 Pacific Time. Following this time, the PMC will hold a vote and suggest the most interesting proposals to the ApacheCon Planning Committee for acceptance to the conference. Note that the Apache HTTP Server PMC does not itself accept session proposals: it merely makes recommendations to the Planning Committee.

Key Dates:

April 4, 2010: Call for Participation closes
May 17, 2010: Speaker Acceptance/Rejection notification
November 1-5, 2010: ApacheCon NA 2010

We look forward to seeing you in Atlanta!

Ubuntu Packages for Perl Modules

The Apache HTTP Server perl-framework testsuite needs a number of Perl modules in order to run. You can install those through CPAN, but on some distributions these modules have been made available through the distro packaging scheme.

This is a quick-and-dirty list of Perl-related packages that need to be installed on a vanilla Ubuntu system in order to run the perl-framework:

Ubuntu Package Perl Module Remarks
libcrypt-ssleay-perl Crypt::SSLeay
libdevel-corestack-perl Devel::CoreStack
libdevel-symdump-perl Devel::Symdump
libdigest-md5-perl Digest::MD5 Part of the default load
liburi-perl URI Part of the default load
  Net::Cmd Part of perl-modules package
  MIME::Base64 Part of perl package
libhtml-tagset-perl HTML::Tagset Default load
libhtml-parser-perl HTML::Parser Default load
libhtml-parser-perl HTML::HeadParser Default load
libwww-perl LWP Default load
libipc-run3-perl IPC::Run3  
libhttp-dav-perl HTTP::DAV Sucks in the following
perl-doc Perl documentation Some files are used as content by some tests

How to Build Apache for Development

This is how I currently build Apache httpd for development and testing.


Once these are in place, check out the Apache source code from http://svn.apache.org/repos/asf/httpd/httpd/trunk, cd into the checkout and run ./buildconf --with-apr=/path/to/apr/source-code. Then run configure:

./configure \
--prefix=/somewhere/convenient \
--enable-mods-shared=all \
--enable-maintainer-mode \
--with-apr=/where/you/put/it \
--enable-proxy=shared \
--enable-ssl=shared \
--enable-case-filter=shared \
--enable-case-filter-in=shared \
--enable-bucketeer=shared \
--enable-echo=shared \

make and make install. This module complement is what will be exercised by the test harness. The build system will leave the last ./configure invocation in config.nice, and also install the latter under the build subdirectory when you make install. Isn’t that nice?

To run the test harness, check out http://svn.apache.org/repos/asf/httpd/test/framework/trunk. Underneath the checkout, find in Apache-Test/lib/Bundle/ApacheTest.pm a list of the Perl modules you need. A number of these will already be on your system. Get what you don’t have from CPAN or your package manager. Also, install HTTP::DAV and its dependencies which is not on the list but needed to exercise mod_dav. Then run:

perl Makefile.PL
t/TEST -httpd /somewhere/convenient/bin/httpd -apxs /somewhere/convenient/bin/apxs

Note your skips and failures. Add Apache modules and Perl modules if you find the list above out of date. Then make your changes to Apache, rebuild and run t/TEST again. If your new build is in a different installation root, run make realclean in the framework and set it up again. When your changes to Apache (no longer) cause any tests to fail, propose the change to dev@httpd.apache.org. If you add new functionality, add new tests. That’s all. Easy.

My ApacheCon US 2009 Wishlist

  • Get Apache HTTP Server building again on Gump (which involves losing the dependency on the Apache Portable Runtime Utility library, which was folded into APR proper)
  • Get @pgollucci what he needs on clarus.apache.org, and work on the future of that box
  • Talk about Apache 2.4, and what is still needed to get that out the door. Then, maybe start talking about figuring out what 3.0 is going to be like
  • Prepare for the Keysigning — which may mean creating a new PGP key
  • Prepare for my presentation on Thursday
  • Do some httpd hacking. Perhaps pull in the ECC patch that has been sitting in Bugzilla

Web Hacking Incident Database Report

The The Web Hacking Incidents Database 2009: Bi-Annual Report is out. If I recall correctly, the first report Breach did, in 2007, did not mention any bi-annualness. Also, the eventual landing page has as HTML title “<title>The Web Hacking Incidents Database 2008: Annual Report</title>”. Is it possible that they simply didn’t get their act together last year and retroactively declared the report bi-annual?

I went in through the link above, gave up my e-mail, phone number and name of my first born, and downloaded the report. This will probably land me another copy of every marketing e-mail Breach sends out (guess how I learned of this report?), and a phone call from some poor guy in a cube who has to make 75 phone calls a day for a living. Oops, guess I put down a fax number. Sorry dude, hope your headset isn’t too loud.

Anyway, after you go though the lead generation form you land here and can follow a direct link to the PDF. This is fairly standard practice, but from a security company I would expect that they would make some more effort to not inadvertedly expose the goods.

ApacheCon US 2009I will give this report a read, and probably discuss it in my upcoming talk at ApacheCon US 2009. Oh, they just extended the early bird registration deadline… without changing their own website to tell you about it. Register now and experience the mayhem.

My First Apache E-mail

Looks like this was my first message to an Apache mailinglist: a suggestion on how to build a recently enhanced ApacheBench on systems that (unlike Mac OS X) don’t have the Math library linked in together with the C library (or libSystem.dylib, as the case may be).