CGI Python user/group permission weirdness

[Aienthiwan]

Hi Sam,

Thanks for your prompt reply, and for all your suggestions.

The process is a cgi python script being called from apache, so it's
the www-data user that apache generated by default.

That idea of making a link is a good one - I'll remember that for next
time.

I tried pretty much all of what you suggested, to know avail. The last
thing I tried shortly after writing this e-mail was going into apache
and switching the Group directive from www-data to dbtest in
httpd.conf to see if that made a difference; and it did.

So it seems to be dropping groups somehow - I did some research on
this and all the evidence in apache documentation let to the contrary.

I didn't want to leave my www-data user by default as dbtest group, so
I tinkered around with it some more, and eventually put it back the
way that it was.

And then everything started working properly.

I wish I had an idea of what I did exactly - serves me right for
attempting this stuff at 5 in the morning I guess.

Well, problem's solved although I don't know exactly why - thx again
for all your help and suggestions!

Regards,
  Aienthiwan


Samuel Walters <swalters_usenet at yahoo.com> wrote in message news:<pan.2004.01.18.10.21.20.719254 at yahoo.com>...
> | Aienthiwan said |
>  
> > Ok - this one's a baffling one.
>  <chop>
> > I have confirmed that it's the www-data user by calling a
> > os.system('whoami') in my script for debugging.
>  <chop>
> > The only inconsistancy is in dbtest and cvs. 
> 
> Have you tried os.system('groups') to verify that the user is in groups
> dbtest and cvs?  Though I can't think of a reason why, maybe the script 
> or the calling process is dropping it's privileges to these groups.

> Have you tried making all the directories leading up to the path of the
> file executable by dbtest and cvs?  Some oddball code may be walking to
> the path, rather than jumping to the file.  How about world executable?
> 
> If you're just testing, you might also try making the files 777 for a
> minute and testing to see if the problem persists.  (Don't leave this in
> production, only use it to isolate the error.)
> 
> Try making a link from the file you want into another directory.  Can you
> access it with the same permissions as the original, or perhaps with
> different permission?
> 
> What www-daemon is this running on?  Some www-daemons can be configured to
> lock down certain directories and var is a likely candidate for that.  Can
> you access other files withing the var directory?  If you fail this test,
> and succeed with the previous two tests, consider that it might be the
> daemon with an out-of-box configuration to keep web-processes out of
> sensitive system areas.
> 
> HTH
> 
> I'll post if I think of anything else.
> 
> Sam Walters.