Re: Apache/PHP/FTP and user rights
On Thu, Aug 01, 2002 at 03:40:23PM +0200, [EMAIL PROTECTED] wrote: Thus : - customers files are uploaded with user.user rights. - Apache runs as www-data.www-data The problem is that with that kind of setup, Apache can't create files in dirs owned by user.user. Even by switching files from user.user to user.www-data, if a file is created by Apache it won't be deletable by FTP. perhaps you should try the cgiwrap package ? there is also a patched version [ hum, heavy patched :) ] which is called 'wrapit', used on Tuxfamily.org, it is part of the VHFFS project, have a look on vhffs.org for more informations... -- Helios de Creisquer http://www.tuxfamily.org/[EMAIL PROTECTED] http://www.vhffs.org/[EMAIL PROTECTED]
Re: Apache/PHP/FTP and user rights
On Thu, 2002-08-01 at 18:38, Phillip Baker wrote: (oops, sent it directly to nicolas instead of the list - resent to the list for other people's benefit) I resigned myself to using cgi-php, mainly because I didn't want users scripts running as the webserver (somewhat of a security risk as then all files readable by the webserver become readable to users php scripts), but also to solve the problem of user's files not belonging to them. My install requires each user to have a copy of the interpreter in their own website's cgi-bin, under /www/their-site-url/cgi-bin - It does mean 2.4mb or so used by each user, but I just credit them the extra quota, and really, 2.4mb isnt so much these days. To change the path you're allowed to use suexec on (because I don't believe you actually use /var/www - do you?) simply recompile it with the different path, and drop it into apache's lib directory. Don't forget to back up your new suexec when you upgrade apache, because apache will overwrite it again! If you need more detailed directives on recompiling suexec for an alternative path let me know and I'll dig the info out. What is the performance hit for this (if any) ? and how much of a PITA is it ? Also, do you have any links ? I've never used suexec, are there any limits on the number of users or such ? Thanks for your time Shri
Re: Apache/PHP/FTP and user rights
Hi Shri, What is the performance hit for this (if any) ? and how much of a PITA is it ? Also, do you have any links ? I've never used suexec, are there any limits on the number of users or such ? I must admit I never did a performance comparison, but from a completely objective point of view it seems plenty fast on my dual p3 1GHz server :) I'm sure theres some performance hit in passing the data inbetween the webserver and PHP using CGI but the interpreter itself shouldn't really be much faster or slower as such, so its shouldn't be too bad. If by user limit if you mean the number of processes running at once, I've certainly not hit any problems to date. As someone pointed out, my individual copies of the PHP binary are unnecessary if you simply hard link to it and make the link belong to the user it should work (I believe) Debian has a php4-cgi (I think it's called) package, but I cant recall in particular what this sets up (if anything). For each virtualhost directive in httpd.conf I have: ScriptAlias /cgi-bin/ /www/website url/cgi-bin/ User username Group groupname (same as username typically in debian) AddType application/x-httpd-php4-cgi .phtml .php4 .php .php3 Action application/x-httpd-php4-cgi /cgi-bin/.php And that works quite well. Naming their interpreter .php hides it from most ftp tools and suchlike and will help prevent them deleting it, although you could always remove write access as well as they shouldn't need to write to the interpreter :) You'll need to recompile suexec if your cgi-bins are outside of /var/www in order for it to work, and overwrite apache's copy. You'll also find suexec won't run files which are not chown'd to the right user and may also refuse to run php that isn't chmod 700. I don't know of any HOWTOs for this, I had to ask someone in the know about it and learnt that way. I do intend to write my own set of HOWTOs for things I've done which don't seem to be particularly well documented at some stage but I've simply not had the time so far :/ If you need a hand at any stage, let me know and I'll do my best to answer your questions. Regards, Phillip Baker LC Host Administrator [EMAIL PROTECTED]
Apache/PHP/FTP and user rights
Dear all, I'm facing a problem I thought would be fairly easy to deal with, but haven't found a proper solution. Here it is : We have a web werver hosting a few tens of customers using VirtualHosts. We have mod_php and use FTP for updates, each customer having its own UID. Thus : - customers files are uploaded with user.user rights. - Apache runs as www-data.www-data The problem is that with that kind of setup, Apache can't create files in dirs owned by user.user. Even by switching files from user.user to user.www-data, if a file is created by Apache it won't be deletable by FTP. What we consider the right solution would be to have Apache run as user.user in each virtual host. This seems to be doable with User/Group directives. Unfortunatly : - mod_php doesn't honor that - using a CGI php requires the use of suEXEC, which in turn requires that the php4 parser be installed in /var/www (hardcoded documentroot) and that it belongs to user.user, which is quite annoying. I tend to think that what I want to do is not something quite unusual. Maybe I missed a straightforward point somewhere. I hope somebody will be able to point me to the right direction. -- Nicolas Bougues Axialys Interactive
Re: Apache/PHP/FTP and user rights
On Thu, Aug 01, 2002 at 03:40:23PM +0200, [EMAIL PROTECTED] wrote: I'm facing a problem I thought would be fairly easy to deal with, but haven't found a proper solution. Here it is : We have a web werver hosting a few tens of customers using VirtualHosts. We have mod_php and use FTP for updates, each customer having its own UID. [...] What we consider the right solution would be to have Apache run as user.user in each virtual host. This seems to be doable with User/Group directives. Unfortunatly : Apache doesn't honor those options in virtual host context, unless run as root and recompiled with some -DBIG_SECURITY_HOLE option. Obviously this is not a very secure solution. Take a look here: http://ftw.zamosc.pl/~lw/mdp/ http://luxik.cdi.cz/~devik/apache/ Wanted
Re: Apache/PHP/FTP and user rights
(oops, sent it directly to nicolas instead of the list - resent to the list for other people's benefit) I resigned myself to using cgi-php, mainly because I didn't want users scripts running as the webserver (somewhat of a security risk as then all files readable by the webserver become readable to users php scripts), but also to solve the problem of user's files not belonging to them. My install requires each user to have a copy of the interpreter in their own website's cgi-bin, under /www/their-site-url/cgi-bin - It does mean 2.4mb or so used by each user, but I just credit them the extra quota, and really, 2.4mb isnt so much these days. To change the path you're allowed to use suexec on (because I don't believe you actually use /var/www - do you?) simply recompile it with the different path, and drop it into apache's lib directory. Don't forget to back up your new suexec when you upgrade apache, because apache will overwrite it again! If you need more detailed directives on recompiling suexec for an alternative path let me know and I'll dig the info out. HTH Regards, Phillip Baker LC Host Administrator [EMAIL PROTECTED] - Original Message - From: [EMAIL PROTECTED] To: debian-isp@lists.debian.org Sent: Thursday, August 01, 2002 2:40 PM Subject: Apache/PHP/FTP and user rights Dear all, I'm facing a problem I thought would be fairly easy to deal with, but haven't found a proper solution. Here it is : We have a web werver hosting a few tens of customers using VirtualHosts. We have mod_php and use FTP for updates, each customer having its own UID. Thus : - customers files are uploaded with user.user rights. - Apache runs as www-data.www-data The problem is that with that kind of setup, Apache can't create files in dirs owned by user.user. Even by switching files from user.user to user.www-data, if a file is created by Apache it won't be deletable by FTP. What we consider the right solution would be to have Apache run as user.user in each virtual host. This seems to be doable with User/Group directives. Unfortunatly : - mod_php doesn't honor that - using a CGI php requires the use of suEXEC, which in turn requires that the php4 parser be installed in /var/www (hardcoded documentroot) and that it belongs to user.user, which is quite annoying. I tend to think that what I want to do is not something quite unusual. Maybe I missed a straightforward point somewhere. I hope somebody will be able to point me to the right direction. -- Nicolas Bougues Axialys Interactive -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Apache/PHP/FTP and user rights
Interesting. A stub runs as root, yes, but all the threads that actually handle requests are running as the correct non-priveleged user on my system. I've never experienced a problem with cgi-php and very much doubt debian would provide it as a package if it provided such a big hole. Regards, Phillip Baker LC Host Administrator [EMAIL PROTECTED] - Original Message - From: Marcin Sochacki [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 01, 2002 4:29 PM Subject: Re: Apache/PHP/FTP and user rights On Thu, Aug 01, 2002 at 03:40:23PM +0200, [EMAIL PROTECTED] wrote: I'm facing a problem I thought would be fairly easy to deal with, but haven't found a proper solution. Here it is : We have a web werver hosting a few tens of customers using VirtualHosts. We have mod_php and use FTP for updates, each customer having its own UID. [...] What we consider the right solution would be to have Apache run as user.user in each virtual host. This seems to be doable with User/Group directives. Unfortunatly : Apache doesn't honor those options in virtual host context, unless run as root and recompiled with some -DBIG_SECURITY_HOLE option. Obviously this is not a very secure solution. Take a look here: http://ftw.zamosc.pl/~lw/mdp/ http://luxik.cdi.cz/~devik/apache/ Wanted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
