[gentoo-user] Re: no suEXEC logging on errors
Jason A. Booth [EMAIL PROTECTED] writes: I have never used suexec, but I would think it better to chown root:apache /usr/sbin/suexec2 or whatever group needs it as apposed to making it world executable I thought it might be a nasty security problem too and asked about it on the apache list. An experienced poster there told me it made very little if any difference which way you went since the users who can use suexec are compiled in at build time. Having it world executable still wouldn't allow some nefarous intruder to run it. But I still felt more comfortable with `root apache' and have since set it that way. A few people have mentioned not having used Suexec making me wonder if there is some other way to allow myuser to run cgi? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: no suEXEC logging on errors
On Thu, Jun 08, 2006 at 01:51:09AM -0500, [EMAIL PROTECTED] wrote: A few people have mentioned not having used Suexec making me wonder if there is some other way to allow myuser to run cgi? I usually run apache as apache:web with the user creating the web stuff in the web group. Justin -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: no suEXEC logging on errors
Justin R Findlay [EMAIL PROTECTED] writes: On Thu, Jun 08, 2006 at 01:51:09AM -0500, [EMAIL PROTECTED] wrote: A few people have mentioned not having used Suexec making me wonder if there is some other way to allow myuser to run cgi? I usually run apache as apache:web with the user creating the web stuff in the web group. I'm not sure of your meaning here. So that gets around needing suexec to fire cgi programs under /home/myuser/public_html? I just tried that or at least tried to. created group web added apache and myuser. renamed /usr/sbin/suexec2/usr/sbin/suexec2X Put the stock httpd.conf in place after setting group to web, and restarted apache. User myuser running firefox can not fire a cgi in public_html they just display in the browser as a text file would. Ditto in /var/www/localhost/htdocs/ Can you clarify what you did? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: no suEXEC logging on errors
Hi, On Thu, 08 Jun 2006 03:37:01 -0500 [EMAIL PROTECTED] wrote: Justin R Findlay [EMAIL PROTECTED] writes: On Thu, Jun 08, 2006 at 01:51:09AM -0500, [EMAIL PROTECTED] wrote: A few people have mentioned not having used Suexec making me wonder if there is some other way to allow myuser to run cgi? I usually run apache as apache:web with the user creating the web stuff in the web group. I'm not sure of your meaning here. So that gets around needing suexec to fire cgi programs under /home/myuser/public_html? For that, there's not even need to put the user in the web group. Just make the files the web server should present world readable (CGI: and world executable). Suexec runs the scripts with a user account. That approach is needed in order to keep (multiple) users on the machine from peeking and poking at each others scripts and data storages. If there's just one user on that machine or security from each other is not an issue, suexec is not needed. What you're experiencing seems to be just a missing ScriptAlias. RTFM about calling CGIs... -hwh -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: no suEXEC logging on errors
Hans-Werner Hilse [EMAIL PROTECTED] writes: What you're experiencing seems to be just a missing ScriptAlias. RTFM about calling CGIs... This is a single user machine so security from users is only a problem from me blundering around... That was why I wanted to keep experimentation at $public_html and a working server for home lan at www/localhost/htdocs. What I've found is that if I set ScriptAlias to /var/www/localhost/cgi-bin/ then it all works there but not at: USER/public_html. There a cgi is just displayed like a file. If I do not define ScriptAlias at all then cgi works under $public_html but cgi under $htdocs is just displayed as a file. I want to be able to fire cgi anywhere under $htdocs or $public_html. How can I do that...? I don't care about suexec if I don't need it. Just another layer of confusion. But if it requires special file permissions root privs in one or the other area then suexec seems easier. RTFM... yes over and over but not really catching on. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: no suEXEC logging on errors
Hi, On Thu, 08 Jun 2006 13:32:17 -0500 [EMAIL PROTECTED] wrote: Hans-Werner Hilse [EMAIL PROTECTED] writes: What you're experiencing seems to be just a missing ScriptAlias. RTFM about calling CGIs... What I've found is that if I set ScriptAlias to /var/www/localhost/cgi-bin/ then it all works there but not at: USER/public_html. There a cgi is just displayed like a file. If I do not define ScriptAlias at all then cgi works under $public_html but cgi under $htdocs is just displayed as a file. Sorry, my fault. A ScriptAlias alone isn't likely to work, if I read this correctly: http://httpd.apache.org/docs/2.0/howto/cgi.html Read starting at CGI outside of ScriptAlias directories, it explicitly mentions the UserDir setting. And there are docs linked for using .htaccess files for configuring this. -hwh -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: no suEXEC logging on errors
Hi, Am Mittwoch, 07. Jun 2006, 18:31:46 -0500 schrieb [EMAIL PROTECTED]: Bertram Scharpf [EMAIL PROTECTED] writes: Am Mittwoch, 07. Jun 2006, 06:29:26 -0500 schrieb [EMAIL PROTECTED]: I'm getting suexec errors in apache error_log. According to all documentation on the subject .. suexec is supposed to log to: /var/log/apache2/suexec_log and `suexec2 -V' shows that as well -D AP_LOG_EXEC=/var/log/apache2/suexec_log I experienced problems with suexec myself, too. In the end, I decided to compile it with the no-suexec USE flag ... I'm not sure what this has to do with getting suexec working. Do you just mean you gave up or what? Yes, sorry, I gave up. Today I happend to retry it and I'm happy to discover: it works. Not actually a very useful contribution, I admit. Bertram -- Bertram Scharpf Stuttgart, Deutschland/Germany http://www.bertram-scharpf.de -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: no suEXEC logging on errors
OK, I assume we are talking about Apache web server here. If that's the case I would suppose you are missing the following in your httpd.conf: - Directory /home/*/public_html/cgi-bin/ Options ExecCGI SetHandler cgi-script /Directory - The whole documentation about mod_userdir which enables per-user web directories: can be found at: http://httpd.apache.org/docs/2.0/howto/public_html.html#page-header -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: no suEXEC logging on errors
[EMAIL PROTECTED] writes: OK, I assume we are talking about Apache web server here. If that's the case I would suppose you are missing the following in your httpd.conf: - Directory /home/*/public_html/cgi-bin/ Options ExecCGI SetHandler cgi-script /Directory Thanks, I seem to have gotten that functionality some other way because currently cgi works anywhere under $public_html. My setting is quite a bit different: Directory /home/*/public_html AllowOverride All Options MultiViews Indexes SymLinksIfOwnerMatch Includes ExecCGI /Directory Yet cgi is recognized and executed anywhere under: Directory /home/*/public_html/ Something that is really puzzling here is that with a default non-inclusive statement like this over '/': Directory / Options FollowSymLinks AllowOverride None /Directory I can still execute all cgi under Directory /home/*/public_html and any subdirectories. However I appears I have to explicitly set execCGI for any sub directories under $htdocs I have these in place but pretty sure they are not very pretty: Directory /var/www/localhost/htdocs/ Options All MultiViews Indexes FollowSymLinks Includes ExecCGI AddHandler cgi-script .cgi AllowOverride All /Directory Directory /var/www/localhost/htdocs/exp Options All MultiViews Indexes FollowSymLinks Includes ExecCGI AddHandler cgi-script .cgi AllowOverride All /Directory I could not execute cgi at /var/www/localhost/htdocs/exp without an explicit Directory statment. If I were to hit a cgi at /var/www/localhost/htdocs/othersub It will not fire but display like file and error log message from apache2 saying I don't have execCGI in that directory. That is, execCGI is recursive under $public_html but only goes one directory at a time under $htdocs (/var/www/localhost/htdocs) I'm pretty sure this is the reason: ScriptAlias /cgi-bin/ /var/www/localhost/cgi-bin/ But without that apache doesn't now about /cgi-bin/ Maybe the ScriptAlias should be set inside the Directory statement of /var/www/localhost? Is that even a possible way to do things? -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: no suEXEC logging on errors
Hans-Werner Hilse [EMAIL PROTECTED] writes: Harry wrote: If I do not define ScriptAlias at all then cgi works under $public_html but cgi under $htdocs is just displayed as a file. Hans-Werner answered: Sorry, my fault. A ScriptAlias alone isn't likely to work, if I read this correctly: http://httpd.apache.org/docs/2.0/howto/cgi.html Read starting at CGI outside of ScriptAlias directories, it explicitly mentions the UserDir setting. And there are docs linked for using .htaccess files for configuring this. A carefull reading of that cgi documentaion doesn't really deal with what happens once you've set a ScriptAlias to /cgi-bin/ What I'm seeing is that once tha that happens any directory under DocumentRoot has to have explicit Options ExecCGI it is not recursive. However, it is recursive at $public_html even though ScriptAlias is set to localhost/cgi-bin/... I don't quite understand why it works like that I guess. Although I can live with having to edit httpd.conf anytime I add a directory under DocumentRoot that might need ExecCGI it just appears inconsisitent. -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: no suEXEC logging on errors
Bertram Scharpf [EMAIL PROTECTED] writes: Yes, sorry, I gave up. Today I happend to retry it and I'm happy to discover: it works. Well no harm done... Now you get to ponder why... hehe. -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: no suEXEC logging on errors
Bertram Scharpf [EMAIL PROTECTED] writes: Hi, Am Mittwoch, 07. Jun 2006, 06:29:26 -0500 schrieb [EMAIL PROTECTED]: I'm getting suexec errors in apache error_log. According to all documentation on the subject .. suexec is supposed to log to: /var/log/apache2/suexec_log and `suexec2 -V' shows that as well -D AP_LOG_EXEC=/var/log/apache2/suexec_log I experienced problems with suexec myself, too. In the end, I decided to compile it with the no-suexec USE flag ... I'm not sure what this has to do with getting suexec working. Do you just mean you gave up or what? I solved my problem by changing permissions on /usr/sbin/suexec2 to from: -rws--x--- 1 root root 10880 May 31 15:09 /usr/sbin/suexec2 -rws--x--x 1 root root 10880 May 31 15:09 /usr/sbin/suexec2 That may not be the best way to do it. Hopefully someone who has more experience will comment about it. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: no suEXEC logging on errors
On Wednesday 07 June 2006 16:31, [EMAIL PROTECTED] wrote: Bertram Scharpf [EMAIL PROTECTED] writes: Hi, Am Mittwoch, 07. Jun 2006, 06:29:26 -0500 schrieb [EMAIL PROTECTED]: I'm getting suexec errors in apache error_log. According to all documentation on the subject .. suexec is supposed to log to: /var/log/apache2/suexec_log and `suexec2 -V' shows that as well -D AP_LOG_EXEC=/var/log/apache2/suexec_log I experienced problems with suexec myself, too. In the end, I decided to compile it with the no-suexec USE flag ... I'm not sure what this has to do with getting suexec working. Do you just mean you gave up or what? I solved my problem by changing permissions on /usr/sbin/suexec2 to from: -rws--x--- 1 root root 10880 May 31 15:09 /usr/sbin/suexec2 -rws--x--x 1 root root 10880 May 31 15:09 /usr/sbin/suexec2 I have never used suexec, but I would think it better to chown root:apache /usr/sbin/suexec2 or whatever group needs it as apposed to making it world executable That may not be the best way to do it. Hopefully someone who has more experience will comment about it. -- -- Jason A. Booth PGP public key(85D1F7FC): http://hyperintelligent.net/~jbooth/jbooth_key.asc -- pgpwP9X8SydCd.pgp Description: PGP signature
