I have a server running PureFTP and Apache.
If I create an FTP user, it gets a directory under /home/ftpusers owned by ftpuser.ftpgroup
I need to create an FTP user that can upload images that the webserver will use (simple: I symlink the directory into the relevant path in DocumentRoot), however I also need Apache to be able to write to the files (images will be uploaded by the website admin backend as well as via FTP).
How do I achieve this?
I can add Apache (www-data) to ftpgroup, which should solve this but would also give Apache write access to all files uploaded by any FTP user, which I don't want to do.
I can make the files world-writeable, which I don't like in principle, but also is going to cause problems as images get uploaded by FTP or Apache (eg new images are not going to inherit the world-write permissions without some changes to the FTP configuration and the web application).
This must be a standard problem with a standard solution?
Mark Rogers mark@quarella.co.uk wrote:
I need to create an FTP user that can upload images that the webserver will use (simple: I symlink the directory into the relevant path in DocumentRoot), however I also need Apache to be able to write to the files (images will be uploaded by the website admin backend as well as via FTP). How do I achieve this?
I can add Apache (www-data) to ftpgroup, which should solve this but would also give Apache write access to all files uploaded by any FTP user, which I don't want to do. [...]
Why would it? If the directory is group-writeable but the files aren't, Apache could delete them (IIRC), but you can avoid that by setting the sticky bit (+t) on the directory. See man chmod.
Maybe I'm not understanding what you're trying to do. Really, apache should be running scripts with suexec or something like that, too.
Hope that helps,
MJ Ray wrote:
Why would it? If the directory is group-writeable but the files aren't, Apache could delete them (IIRC), but you can avoid that by setting the sticky bit (+t) on the directory. See man chmod.
The files would need to be group-writable for Apache to be able to write to them, but the way PureFTP works (with virtual FTP users) is that all files from all users have ftpuser.ftpgroup ownership, so adding Apache to ftpgroup would give Apache write access to all FTP users' files.
I think +t might have some part in the solution, although I'm not sure of the bigger picture yet. I'm not sure what the benefit of preventing deletion is if the file can still be changed.
Maybe I'm not understanding what you're trying to do. Really, apache should be running scripts with suexec or something like that, too.
I've never found an elegant solution for Apache using suexec. Certainly it would be helpful if all virtual hosts ran as separate users (without a significant performance impact) but last I looked at that it wasn't simple to achieve what I wanted (sorry to be vague, it was some time ago I last looked at this and I don't now recall what was the issue).
Mark Rogers mark@quarella.co.uk wrote:
MJ Ray wrote:
Why would it? If the directory is group-writeable but the files aren't, Apache could delete them (IIRC), but you can avoid that by setting the sticky bit (+t) on the directory. See man chmod.
The files would need to be group-writable for Apache to be able to write to them,
Why does Apache need to be able to write to the files? I thought the problem was "images will be uploaded by the website admin backend as well" so I dismissed your "write to the files" statement as misleading. I thought that you wanted Apache to be able to write new files to that directory (so the directory is +t and g+w), but avoid allowing it to write to the actual files uploaded by PureFTP (so the files don't need to be g+w).
but the way PureFTP works (with virtual FTP users) is that all files from all users have ftpuser.ftpgroup ownership, so adding Apache to ftpgroup would give Apache write access to all FTP users' files.
Surely not, as long as PureFTP isn't creating the files g+w? If it is, then I think your umask is wrong for your need. See http://download.pureftpd.org/pub/pure-ftpd/doc/README http://download.pureftpd.org/pub/pure-ftpd/doc/README.Configuration-File for how to change it.
Hope that helps,
MJ Ray wrote:
Why does Apache need to be able to write to the files? I thought the problem was "images will be uploaded by the website admin backend as well" so I dismissed your "write to the files" statement as misleading. I thought that you wanted Apache to be able to write new files to that directory (so the directory is +t and g+w), but avoid allowing it to write to the actual files uploaded by PureFTP (so the files don't need to be g+w).
Not quite!
I want Apache to be able to upload images, and I want the user to be able to "change" (by which I mean overwrite, delete, etc) those images via FTP, and I need Apache to also be able to overwrite the files with new uploads.
What I do *not* want to do is give the Apache process write access to the files of all other FTP users at the same time.
but the way PureFTP works (with virtual FTP users) is that all files from all users have ftpuser.ftpgroup ownership, so adding Apache to ftpgroup would give Apache write access to all FTP users' files.
Surely not, as long as PureFTP isn't creating the files g+w?
If it isn't, then it needs to be in order for me to be able to allow Apache to overwrite the files!
This is back where I started: this cannot be the right way to achieve what I need but I don't know what the right way is. To repeat: I need a directory of files of one FTP user to be read/write for the FTP user *and* read/write for Apache, without making files for other FTP users accessible to Apache.
The "correct" solution would seem to be that each virtual host should run as a different user, and the FTP users should be distinct also, so that each site has an FTP user with read/write access, and an Apache user with read only access (except where write access needs to be specifically granted). I guess with suexec I could do this (but I have no experience of this and I got the impression previously that I'd have to move away from PHP Apache modules to CGI?), or suphp (which I got into a hell of a muddle with last time I tried it, but that's probably just me!).
-
Mark Rogers -
MJ Ray