Hi Marco Thanks for the tips, they were what I was thinking was the problem, that even when the php cgi was owned by the correct user, that if it was being called via another web based script, that it would be executed as apache (in this case) rather than the actual owner of the cgiscript (vpopmail/vchkpw), the same ower/group as the target file. I had thought that if I used setuid/gid on the cgi script that it would execute as that user, rather than apache tho.
I didnt want to waste even more bandwidth by posting the code and all the other details, I had hoped I had provided enough for some educated guesses which may have led me to a solution, or what details to provide to help in a solution As I said, this was the first time I had attempted this precise situation (that of executing a script as another user other than the web server), I cant change the permissions on the getmailrc file, or the getmail program wont read it, a bit of a catch 22 :( it seems. > Without seeing your code... only one guess: what are the permissions on > the file like? The actual php cgi??? its [root@alpha cgi-bin]# ls -lA get* -rwxrwxr-x 1 root root 6107 Oct 13 00:44 getmailtest.cgi but I have messed with it, trying different combos including vpopmail:vchkpw (the target file owner) all set as world executable the permissions on the getmailrc file (the target file) are in my original post.... but to show it again, it is -rw-r--r-- 1 vpopmail vchkpw 585 Sep 29 07:16 getmailrc > When you're running the script from the web server, > you're running it as the user under which the web server is running > (usually nobody or apache if you're using Apache on Linux), and this > causes problem if that particular user doesn't have access to the file. which is why I thought (stressing thought.. like I said.. Ive never tried this approach before) that the setuid/gid may have been the solution, although testing did appear to indicate that it was executed as the web server user when it is accessed via a click or button from the web, ignoring the setuid etc...Like I was saying I may be trying somethign that is really tough, but basically I wanted to partition out the part of the process that may have security implications, and just pass a single variable to it, executing it on demand, rather than via cron (though it does work via cron.. its not the best solution in my case.. but may be one I have to look at) > > There are very few solutions to this problem (at least as far as I > know). One is the suexec module for Apache, that lets you impersonate > root or another user, but you have to be *extremely* careful with the > permissions. The other is to change the default permissions of the file > so that everyone can delete and modify it, but that might not work well > for your needs. Yet a third one would be to impersonate directly from > PHP, for example through a call to su, but there are pitfalls there as > well. Even though I would reallyyy prefer NOT to go anywhere near su (cause security is my primary focus in splitting out any file system writes to a separate process) how would using su help out??? I havent done that either so far (have never run into a situation like this before) Thanks again for the reply... I will keep working on it.. and post back if I get any further Regards David Cook -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
