Opened 11 years ago

Last modified 23 months ago

#38461 new request

Port request: apache_mod_hfs_apple

Reported by: cooljeanius (Eric Gallager) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: vikingjs@…, danielluke (Daniel J. Luke), ryandesign (Ryan Carsten Schmidt), mp@…, Schamschula (Marius Schamschula)
Port: apache_mod_hfs_apple

Attachments (3)

mod_hfs_apple-portfile-20130910 (1.9 KB) - added by mp@… 11 years ago.
www-mod_hfs_apple-portfile - version 14
mod_hfs_apple-portfile-20130910-with-notauto (2.8 KB) - added by mp@… 11 years ago.
Portfile with variant +notauto – to not automatically modify apache2 configuration files
mod_hfs_apple-portfile-20130911-auto (2.9 KB) - added by mp@… 11 years ago.
Portfile with variant +auto, set as default, to automatically modify apache2 configuration files and restart apache2 if it's running

Download all attachments as: .zip

Change History (23)

comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Actually it was originally requested in #803. :)

comment:2 Changed 11 years ago by danielluke (Daniel J. Luke)

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

comment:3 Changed 11 years ago by 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?)

comment:6 Changed 11 years ago by mp@…

Cc: mp@… added

Cc Me!

Changed 11 years ago by mp@…

www-mod_hfs_apple-portfile - version 14

comment:7 Changed 11 years ago by 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)

comment:8 in reply to:  7 ; Changed 11 years ago by 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.

comment:9 in reply to:  8 Changed 11 years ago by 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...

Last edited 11 years ago by cooljeanius (Eric Gallager) (previous) (diff)

Changed 11 years ago by mp@…

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

comment:10 Changed 11 years ago by 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.

comment:11 Changed 11 years ago by 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.

comment:12 in reply to:  10 ; Changed 11 years ago by 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.

comment:13 in reply to:  12 Changed 11 years ago by 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

Changed 11 years ago by mp@…

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

comment:14 in reply to:  11 ; Changed 11 years ago by 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?

comment:15 Changed 11 years ago by 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.

comment:16 in reply to:  14 ; Changed 11 years ago by 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.

comment:17 in reply to:  16 Changed 11 years ago by 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.

comment:18 Changed 11 years ago by 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.

comment:19 Changed 6 years ago by Schamschula (Marius Schamschula)

Cc: Schamschula added

comment:20 in reply to:  18 Changed 23 months ago by 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

Note: See TracTickets for help on using tickets.