IMSoP's questions

I have a proxy configuration under Apache 2.2 which passes all requests for /blog to a host I have no control over.

I want to unset a particular HTTP header (X-Powered-By: PHP) from the proxied response, so that it is not visible to the browser.

I tried this:

ProxyPass /blog http://blog.example.com
ProxyPassReverse /blog http://blog.example.com
Header Always Unset X-Powered-By

And also this variation:

<Location /blog>
    ProxyPass http://blog.example.com
    ProxyPassReverse http://blog.example.com
    Header Always Unset X-Powered-By
</Location>

In both cases, the header is sent through unchanged from the proxy. I also tried Header Always Edit, also no effect.

Interestingly, if I use Header Always Set X-Powered-By Test, the resulting response contains X-Powered-By: Test, PHP - i.e. my value is added before the one from the proxy. I suspect mod_proxy is running "too late" for mod_headers to manipulate the response.

Is there a way to make Header run "later", or some other directive which could manipulate the response after it comes back from the proxy.

When setting up an FTP account for a specific purpose - e.g. as a drop-point for sharing data files - it seems sensible to give the user access only to the particular directory, and no view of a wider file system.

On *nix systems, in particular, every user generally has read access to a lot of system files such as /etc/passwd. FTP daemons generally allow you to hide these by executing a chroot on login, so that the user is in a virtual "jail".

But chroot was not designed as a security measure [archive copy as site seems down], and can even introduce security problems of its own; for this reason, vsftpd restricted this feature such that you can only chroot to a read-only directory, and the user must then navigate into a sub-directory to perform any write operations. ProFTPD warns of the problem but offers no alternative, and PureFTPD requires various special files to be created in order to even use a chroot.

It seems to me that there is no fundamental reason for the FTP access to map to the OS's notion of filesystem access at all; like an HTTP daemon, an FTP daemon could "rewrite" all requests according to a set of configuration rules. If you ask an Apache web host for the path /, it maps that to the directory defined in the DocumentRoot directory, not to the host OS's current / directory.

My question is, does any *nix FTP daemon use a "rewriting" mechanism like this (or some other way of limiting access), and if not, is there a fundamental reason?

Note: there is some overlap with this existing question, but the answers primarily discuss whether to use chroot or not, rather than complete alternatives.