Web Hosting Talk







View Full Version : suexec in apache


mancu
03-04-2002, 02:15 AM
I've complied apache with suexec.

Now, how to set httpd.conf to get customer website run cgi script like php in safemode.

Thanks

serve-you
03-04-2002, 02:27 AM
I don't quite follow your question here. Are you having trouble running a cgi script under suexec?

-Dan

mancu
03-04-2002, 03:32 AM
Thaks Dan.
I've no problem with run normal CGI script.

but on my customer, he can write .cgi to read other content file in other website. so, we need to protect it.

Thanks again for your post.

serve-you
03-04-2002, 03:50 AM
Ahhh.
That is not something to be solved by suexec. That would be due to permissions of your user directories. There has been quite a bit of discussion on this subject here in the past, with some good pointers. Do a search for 'security permissions' or something similar, and I'm sure you will find tons of help.

-Dan

bitserve
03-05-2002, 11:40 PM
Seems to me like if the CGI script was running as the same user as the webserver runs as, that it would be able to read other user's documents, even if the permissions were set up correctly.

suexec and permissions will solve the CGI problem on a shared apache server.

After you've compiled with suexec, you need to actually specify the user and group in the virtual host directives, and make sure that apache is starting with suexec. You can do this by just looking at your error log for this:

suEXEC mechanism enabled

If you don't see that, then you may have something configured incorrectly.

mancu
03-06-2002, 01:48 AM
Thanks bitserve.

could u post a sample of virtualhost directive for user and group?

serve-you
03-06-2002, 01:55 AM
You just need to add:

User username
Group groupname

-Dan

mancu
03-06-2002, 02:53 AM
Thanks

i've added user, group as you posted.

but the cgi of other site still can read content of all sites in shared hosting, still read system unix file.

How to do next.

serve-you
03-06-2002, 02:58 AM
Like I stated before, this is a permissions issue, not a suexec issue. If your users have read permissions in another directory, then they can execute scripts within their own directories, that can look elsewhere.

-Dan

mancu
03-06-2002, 03:02 AM
the script can read any directory even mod 755

can we protect it?

joethong
03-06-2002, 07:15 AM
Hi,

Try these, its taken from a thread discussing about securing users' home directories. If I'm not mistaken, tim_greer suggested something like this:

Set Apache to run as user "apache" and the group as "www" or something.

Add that group (www) and do:

chmod 711 /home
chmod 750 /home/username
chown username.www /home/username

(no need to set the GID on any other file or directory, other than the main/parent useraccount directory, btw. So don't do that recursively or with any other file or dir.)

This will prevent your customers snooping around in other people directories.

Later.
Joe

priyadi
03-06-2002, 09:46 AM
Also, you need to disable Option FollowSymLinks, and optionally replace it by SymLinksIfOwnerMatch. Otherwise a user can use symlinks to read other users' files.

bitserve
03-07-2002, 01:43 AM
Originally posted by mancu
Thanks

i've added user, group as you posted.

but the cgi of other site still can read content of all sites in shared hosting, still read system unix file.

How to do next.

I don't know how dan guessed that even when your suexec was configured correctly that you're permissions were all haywire, but he did. Way to go dan!

Do what joe suggested to stop users from reading eachother's files.

Those "system unix files" that you don't want them to view you need to go through and change the permissions on each one so that others can't read them. I'd start with the /var/log directory, which should be safe to just modify the perms on all of them.

chmod o-xrw -R /var/log

After that, you might want to go through each file one at a time and decide if it's safe or not. You could also take your chances and run a hardening script like bastille. Still, the best way is to go through each directory and if the user doesn't need access, take it away.