Hi David-- If that is the issue then I would suggest looking into the suexec module for Apache...as long as you're very careful with the permissions, you should be fine!
Also, my reference to the code was more a "caveat" than anything else. In your case, if the script was working from the sell, imho you made a good decision not to post the source, since the problem was clearly somewhere else. Marco On Sun, 2002-10-13 at 11:20, David Cook wrote: > 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 > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
