Port request: apache_mod_hfs_apple

[cooljeanius (Eric Gallager)]

​http://opensource.apple.com/source/apache_mod_hfs_apple/

Originally requested in #38452

[ryandesign (Ryan Carsten Schmidt)]

Actually it was originally requested in #803. :)

[danielluke (Daniel J. Luke)]

There's a version 12 available now, which says Copyright (c) 2000-2013 Apple Inc. All Rights Reserved

[danielluke (Daniel J. Luke)]

Note that it builds fine and seems to be operating on my non-macports httpd-2.4.4. install on 10.5/ppc. It would probably be a good addition for MacPorts (and maybe even something we push out with any Apache install on Darwin?)

[danielluke (Daniel J. Luke)]

​http://opensource.apple.com/tarballs/apache_mod_hfs_apple/apache_mod_hfs_apple-12.tar.gz

[cooljeanius (Eric Gallager)]

It's up to v14 as of 10.8.4: ​http://opensource.apple.com/tarballs/apache_mod_hfs_apple/apache_mod_hfs_apple-14.tar.gz

[mp@…]

Cc Me!

[mp@…]

www-mod_hfs_apple-portfile - version 14

[mp@…]

A Portfile for mod_hfs_apple is now available in attachment:mod_hfs_apple-portfile-20130910​

The current version is 14, which means it is based on the module source in ​http://opensource.apple.com/source/apache_mod_hfs_apple/apache_mod_hfs_apple-14/ , which solves the vulnerability in apache2 with HFS, where the source of .php files is served by apache2 instead of being evaluated.

So, ​http://localhost/index.p%E2%80%8Chp now doesn't reveal the source of index.php, as shown in ticket:38452 (and ​http://packetstormsecurity.com/files/120820/Apple-Security-Advisory-2013-03-14-1.html).

Since I'm only running Tiger at the moment, that is what it is tested on, but it should work on any OS X version.

Even though I'm quite pleased with the solution - where activation/deactivation is completely controlled by the port command - comments and any possible improvements are most welcome.

---

As it is now, upon installation/activation of the port,

LoadModule hfs_apple_module   modules/mod_hfs_apple.so

is automagically added to the apache configuration file, and apache2 gracefully restarted.
(post-activate: apxs -e -a)

If the port is deactivated, the module is first commented out in the apache2 configuration file, apache2 restarted gracefully, and then the module is removed.
(pre-deactivate: apxs -e -A)

[ryandesign (Ryan Carsten Schmidt)]

Replying to mp@…:

As it is now, upon installation/activation of the port,

LoadModule hfs_apple_module   modules/mod_hfs_apple.so

is automagically added to the apache configuration file, and apache2 gracefully restarted.
(post-activate: apxs -e -a)

If the port is deactivated, the module is first commented out in the apache2 configuration file, apache2 restarted gracefully, and then the module is removed.
(pre-deactivate: apxs -e -A)

That is interesting however I am concerned that it will be unexpected for users since to my knowledge no other ports do that kind of thing. Editing configuration file and starting, stopping or restarting servers have always been activities that users are expected to do on their own. Ports can of course advise users what they should do, via a notes command.

[cooljeanius (Eric Gallager)]

Replying to ryandesign@…:

Replying to mp@…:

As it is now, upon installation/activation of the port,

LoadModule hfs_apple_module   modules/mod_hfs_apple.so

is automagically added to the apache configuration file, and apache2 gracefully restarted.
(post-activate: apxs -e -a)

If the port is deactivated, the module is first commented out in the apache2 configuration file, apache2 restarted gracefully, and then the module is removed.
(pre-deactivate: apxs -e -A)

That is interesting however I am concerned that it will be unexpected for users since to my knowledge no other ports do that kind of thing. Editing configuration file and starting, stopping or restarting servers have always been activities that users are expected to do on their own. Ports can of course advise users what they should do, via a notes command.

As a user, I've always wished that more ports would do this for me, instead of just telling me to do it myself. Edit: Although on the other hand, I can also see why other users might not want this though... maybe there could be some sort of option? Not sure what kind or where I'm going with this idea though...

[mp@…]

Portfile with variant +notauto – to not automatically modify apache2 configuration files

[mp@…]

A revised Portfile with the variant +notauto has been added.
attachment:mod_hfs_apple-portfile-20130910-with-notauto​

Selecting +notauto causes the installation/activation to not modify the apache2 configuration file.

Normally I am also against programs fiddling with configuration files, but several points caused me to reconsider in this case:

• a severe security hole is mended with this module, so it should be quick and easy to install for anyone
• apxs, which makes the change in the configuration, is part of apache2 and made specifically for this purpose
• the hfs_apple module has no other settings that can be tweaked, so the only thing to do is to get it running
• one installs this module because one wants it to just work smoothly right away
• no adverse side effects when adding/removing the module in the configuration file – only that is done.

These are also the reasons why I chose the variant to be +notauto and not +auto.

(If the module is deactivated/uninstalled, apxs is always invoked to disable the module – by commenting out the appropriate LoadModule line – because otherwise apache2 would fail during the next start.)

On another note, I consider the security hole that this module mends to be so severe, that I would prefer to have this module installed together with apache2 by default.

[danielluke (Daniel J. Luke)]

Macports policy would be to have +auto and set it as a default variant (we don't do negative variants anymore).

Having said that, I would rather have this act like all of the other apache module ports /or/ have this included in the macports-provided apache and enabled by default on Mac OS X systems.

[larryv (Lawrence Velázquez)]

Replying to mp@…:

On another note, I consider the security hole that this module mends to be so severe, that I would prefer to have this module installed together with apache2 by default.

If our default Apache configuration is really that insecure, I’d consider it irresponsible of us to not automatically fix it for all users. We shouldn’t even let them turn it off.

[pixilla (Bradley Giesbrecht)]

Replying to larryv@…:

If our default Apache configuration is really that insecure, I’d consider it irresponsible of us to not automatically fix it for all users. We shouldn’t even let them turn it off.

+1

[mp@…]

Portfile with variant +auto, set as default, to automatically modify apache2 configuration files and restart apache2 if it's running

[mp@…]

Replying to dluke@…:

Macports policy would be to have +auto and set it as a default variant (we don't do negative variants anymore).

As suggested, a revised Portfile with the variant +auto set as default has been added.
attachment:mod_hfs_apple-portfile-20130911-auto​

Having said that, I would rather have this act like all of the other apache module ports /or/ have this included in the macports-provided apache and enabled by default on Mac OS X systems.

Is there a way to trigger a sort-of "post-requisite" in MacPorts, so that mod_hfs_apple could get installed automatically after apache2? Maybe even as a default variant of apache2?

[pixilla (Bradley Giesbrecht)]

Regarding installing default apache2 modules:

Apache24-devel has been added to MP in r110953. Unlike the current apache2 port the apache24-devel port does not violate porthier.

There is also now an apache2 port group r110954 which has some provisions for building apache modules. This apache2 port group is intended to be used for building apache2 modules along with apache2.

The apache24-devel has some commented out code intended to install default apache modules utilizing the apache2 PortGroup.

The goal of the apache24-devel is to be replaced_by apache2.

Hopefully soon we can switch to apache 2.4.x.

[larryv (Lawrence Velázquez)]

Replying to mp@…:

Is there a way to trigger a sort-of "post-requisite" in MacPorts, so that mod_hfs_apple could get installed automatically after apache2? Maybe even as a default variant of apache2?

The Apache portfile itself should install the mod_hfs_apple module unconditionally. There should be no variant, as variants provide a choice.

[ryandesign (Ryan Carsten Schmidt)]

Replying to larryv@…:

The Apache portfile itself should install the mod_hfs_apple module unconditionally. There should be no variant, as variants provide a choice.

Yeah I agree. We can also modify the default httpd.conf file to activate it for new users. However we still have to decide whether to automatically modify existing users' httpd.conf files and in that case whether or not to automatically restart the server for them. I'm inclined to modify the conf file, even though that's not usually done, because users probably won't know they should do it, and notes can be easily overlooked. The port could print a message telling them this has been done. However I would not restart the server automatically because users should already be in the habit of doing that after upgrading a port that provides a server, and/or it should be something MacPorts base would take care of for all ports.

[danielluke (Daniel J. Luke)]

I would say it's fine to leave the configuration we've been shipping for forever alone (but print something in notes). Disclosing the contents of .php files shouldn't be a security risk with a well-architected application anyway.

[cooljeanius (Eric Gallager)]

Replying to danielluke:

I would say it's fine to leave the configuration we've been shipping for forever alone (but print something in notes). Disclosing the contents of .php files shouldn't be a security risk with a well-architected application anyway.

Related to the topic of leaving configurations alone: bug #2365