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.


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

Reply via email to