Re: [OT] Backup on DLT (recommandation)
On Saturday 08 January 2005 17.46, Michelle Konzack wrote: [Tapes] My only problem is that my purse is very limited to =700 Euro. If you believe their advertisement, Exabytes VXA tapes are a cost-effective solution, compared to other tape solutions. I have no experience with them, I just thought I'd point you in that direction if you haven't investigated them yet. -- vbi -- Today is Setting Orange, the 10th day of Chaos in the YOLD 3171
suexec permissions
Good morning, I'm having a some permissions trouble with suexec running on Sarge. I have a virtualhost for a user called Bob which specifies User Bob and Group Bob in the /etc/apache/conf.d/bob.conf file. The permissions on /var/www/bob are: drwx-- 2 bob bob 4096 Jan 10 10:30 cgi-bin drwx-- 26 bob bob 4096 Jan 10 10:30 htdocs and the permissions on /var/www/bob/htdocs/index.html are: drwx-- 1 bob bob 4096 Jan 10 10:30 index.html When I restart Apache, I get the following message in the Apache error log: [Mon Jan 10 10:35:00 2005] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache/suexec) But when I try to access index.html, bob's error log shows: [Mon Jan 10 10:36:00 2005] [error] [client 10.1.1.1] (13)Permission denied: access to /index.html failed because search permissions are missing on a component of the path If I switch user to bob, and run ls -la on /, /var, /var/www, /var/www/bob I can see all of the files, so why is apache running as this user not able to?
Re: suexec permissions
nodata wrote: Good morning, I'm having a some permissions trouble with suexec running on Sarge. I have a virtualhost for a user called Bob which specifies User Bob and Group Bob in the /etc/apache/conf.d/bob.conf file. snip If I switch user to bob, and run ls -la on /, /var, /var/www, /var/www/bob I can see all of the files, so why is apache running as this user not able to? Hiya, You'll probably find that all your Apache processes are running as www-data based on the User directive in your main httpd.conf -- and they can't read bob's files. Only CGI scripts will be affected by the User directive in a VirtualHost. From: http://httpd.apache.org/docs/mod/core.html#user Special note: Use of this directive in VirtualHost requires a properly configured suEXEC wrapper. When used inside a VirtualHost in this manner, only the user that CGIs are run as is affected. Non-CGI requests are still processed with the user specified in the main User directive. Regards, Blair. signature.asc Description: OpenPGP digital signature
Re: suexec permissions
Blair Strang wrote: nodata wrote: Good morning, I'm having a some permissions trouble with suexec running on Sarge. I have a virtualhost for a user called Bob which specifies User Bob and Group Bob in the /etc/apache/conf.d/bob.conf file. snip If I switch user to bob, and run ls -la on /, /var, /var/www, /var/www/bob I can see all of the files, so why is apache running as this user not able to? Hiya, You'll probably find that all your Apache processes are running as www-data based on the User directive in your main httpd.conf -- and they can't read bob's files. Only CGI scripts will be affected by the User directive in a VirtualHost. From: http://httpd.apache.org/docs/mod/core.html#user Special note: Use of this directive in VirtualHost requires a properly configured suEXEC wrapper. When used inside a VirtualHost in this manner, only the user that CGIs are run as is affected. Non-CGI requests are still processed with the user specified in the main User directive. Therefore, if you have a user called bob, and a group called bob, make the files group readable, and make the user www-data a member of that group. That should do it. Forget suexec, it is far more complicated than what it sounds like you need. Regards, Upayavira
Re: suexec permissions
discussion of User directive in VirtualHost elided nodata wrote: Ah this would explain things more - but then shouldn't running http://website/cgi-bin/test.pl work? I get the same search permissions error.. Er, yep, as far as I can see, it should. suEXEC can be a little... finicky :) What does /var/log/apache/suexec.log say? Ta, Blair. signature.asc Description: OpenPGP digital signature
Re: suexec permissions
discussion of User directive in VirtualHost elided nodata wrote: Ah this would explain things more - but then shouldn't running http://website/cgi-bin/test.pl work? I get the same search permissions error.. Er, yep, as far as I can see, it should. suEXEC can be a little... finicky :) What does /var/log/apache/suexec.log say? Nothing :/ But the error log for this host has the failed because search permissions are missing on a component of the path error. Ta, Blair. ps. I'm also using binfmt with php4-cgi to serve php pages, this might be relevant later.
Re: suexec permissions
On Monday 10 January 2005 11:34, nodata wrote: nodata wrote: From: http://httpd.apache.org/docs/mod/core.html#user Special note: Use of this directive in VirtualHost requires a properly configured suEXEC wrapper. When used inside a VirtualHost in this manner, only the user that CGIs are run as is affected. Non-CGI requests are still processed with the user specified in the main User directive. Ah this would explain things more - but then shouldn't running http://website/cgi-bin/test.pl work? I get the same search permissions error.. Why of course. The server doesn't 'know' anything about that file (or that it even exists) until it can 'stat' it. And now it _cannot_ stat it ;-) It sound like a chicken and egg problem to me. Maarten
Re: suexec permissions
On Monday 10 January 2005 11:34, nodata wrote: nodata wrote: From: http://httpd.apache.org/docs/mod/core.html#user Special note: Use of this directive in VirtualHost requires a properly configured suEXEC wrapper. When used inside a VirtualHost in this manner, only the user that CGIs are run as is affected. Non-CGI requests are still processed with the user specified in the main User directive. Ah this would explain things more - but then shouldn't running http://website/cgi-bin/test.pl work? I get the same search permissions error.. Why of course. The server doesn't 'know' anything about that file (or that it even exists) until it can 'stat' it. And now it _cannot_ stat it ;-) It sound like a chicken and egg problem to me. Maarten Ah. So what do other people do? I could chgrp www-data, but then suexec complains. I could give o+rx access, but then I'm left with anyone on the machine being able to read everything. Is there a simple solution?
linux virtual server and coda
I'm evalutating a HA architecure based on LVS. Coda fs is a possible choice for distributed files among the real servers. It would be used for generic files, not for the DBMS, of course. Is it an affordable solution? Does anyone have first hand experiences with it? -- Francesco P. Lovergine
Re: suexec permissions
nodata wrote: discussion of User directive in VirtualHost elided nodata wrote: Ah this would explain things more - but then shouldn't running http://website/cgi-bin/test.pl work? I get the same search permissions error.. Er, yep, as far as I can see, it should. suEXEC can be a little... finicky :) What does /var/log/apache/suexec.log say? Nothing :/ But the error log for this host has the failed because search permissions are missing on a component of the path error. A couple of things. The suEXEC wrapper itself does setuid() before most of the path/file checks, so that's probably not the problem. The absence of anything in the log file also indicates that Apache itself is having trouble reading things, not the suEXEC wrapper. You might want to try loosening the read permissions on the CGI + path to the CGI, and verify (by perhaps touching a file in /tmp) that it is running as the user you intended it to. Then try tightening the read permissions on the CGI itself, and then along the path to it. The other thing to check is that your scripts are physically located under suEXEC's DOC_ROOT (/var/www on Sarge, I think). Regards, Blair. signature.asc Description: OpenPGP digital signature
Re: suexec permissions
On Monday 10 January 2005 12:05, nodata wrote: On Monday 10 January 2005 11:34, nodata wrote: nodata wrote: Ah this would explain things more - but then shouldn't running http://website/cgi-bin/test.pl work? I get the same search permissions error.. Why of course. The server doesn't 'know' anything about that file (or that it even exists) until it can 'stat' it. And now it _cannot_ stat it ;-) It sound like a chicken and egg problem to me. Maarten Ah. So what do other people do? Dunno, I'm not really into apache in a deep way. I could chgrp www-data, but then suexec complains. I could give o+rx access, but then I'm left with anyone on the machine being able to read everything. Experiment. Maybe setting 711 on the directories leading up to that file changes things enough ? Or maybe leaving all dirs 755 (but not the files itself) fixes it and leaves enough security for your setup ? Try it. Maarten --
Re: suexec permissions
nodata wrote: discussion of User directive in VirtualHost elided nodata wrote: Ah this would explain things more - but then shouldn't running http://website/cgi-bin/test.pl work? I get the same search permissions error.. Er, yep, as far as I can see, it should. suEXEC can be a little... finicky :) What does /var/log/apache/suexec.log say? Nothing :/ But the error log for this host has the failed because search permissions are missing on a component of the path error. A couple of things. The suEXEC wrapper itself does setuid() before most of the path/file checks, so that's probably not the problem. The absence of anything in the log file also indicates that Apache itself is having trouble reading things, not the suEXEC wrapper. You might want to try loosening the read permissions on the CGI + path to the CGI, and verify (by perhaps touching a file in /tmp) that it is running as the user you intended it to. Then try tightening the read permissions on the CGI itself, and then along the path to it. Done. chmod o+rx on: /var/www/bob /var/www/bob/htdocs /var/www/bob/cgi-bin then running a system(touch /tmp/blairtest) from cgi-bin/test.pl creates a file with bob:bob permissions. The other thing to check is that your scripts are physically located under suEXEC's DOC_ROOT (/var/www on Sarge, I think). They are. Regards, Blair. The problem with this setup is that I have to have o+rx permission on directories and non-executables, which is a little messy (and I'm not sure whether vsftpd can handle this). Plus everyone on the machine can now read the files. Ack.
Re: suexec permissions
nodata wrote: Done. chmod o+rx on: /var/www/bob /var/www/bob/htdocs /var/www/bob/cgi-bin then running a system(touch /tmp/blairtest) from cgi-bin/test.pl creates a file with bob:bob permissions. The other thing to check is that your scripts are physically located under suEXEC's DOC_ROOT (/var/www on Sarge, I think). They are. Regards, Blair. The problem with this setup is that I have to have o+rx permission on directories and non-executables, which is a little messy (and I'm not sure whether vsftpd can handle this). Plus everyone on the machine can now read the files. Ack. Well, to get /proper/ isolation you have to run separate Apache instances... :) You could try a compromise along the lines of that suggested by Upayavira, except you hit NGROUPS_MAX as you noted. Wild Ass Suggestion: If you made each user VirtualHost directory uid user gid www-data, and mode 2750 (note the setgid bit there), and have only Apache in group www-data, might that not work? [Am I missing something obvious?] The biggest problem then is that users can piggyback off Apache's group www-data access by running scripts. Perhaps this could be surmounted with suexec, by forcing scripts to run as the User/Group you specify. Users might have to manually chgrp their scripts to their User Private Group in this scenario though, which is a disadvantage. But I should shut up now... I have to defer at this point to someone with more experience at running large Apache installations. 8-P Regards, Blair. signature.asc Description: OpenPGP digital signature
Re: suexec permissions
The problem with this setup is that I have to have o+rx permission on directories and non-executables, which is a little messy (and I'm not sure whether vsftpd can handle this). Plus everyone on the machine can now read the files. Ack. Well, to get /proper/ isolation you have to run separate Apache instances... :) You could try a compromise along the lines of that suggested by Upayavira, except you hit NGROUPS_MAX as you noted. Wild Ass Suggestion: If you made each user VirtualHost directory uid user gid www-data, and mode 2750 (note the setgid bit there), and have only Apache in group www-data, might that not work? [Am I missing something obvious?] I think I'd get an error from suexec complaining about a User/Group mismatch. The biggest problem then is that users can piggyback off Apache's group www-data access by running scripts. Perhaps this could be surmounted with suexec, by forcing scripts to run as the User/Group you specify. Users might have to manually chgrp their scripts to their User Private Group in this scenario though, which is a disadvantage. But I should shut up now... I have to defer at this point to someone with more experience at running large Apache installations. 8-P Regards, Blair. Anyone? :)