«

Ok - this one's a baffling one.

I have a Python script run in cgi, it accesses a directory...
/var/foo.

The permissions on /var/foo are 770 with an ownership of mark:dbtest.
The permissions on /var are 755.

In my /etc/group file, www-data is part of the www-data, dbtest,
fusion and cvs groups.

I get an exception thrown with a permission denied on /var/foo.

I have confirmed that it's the www-data user by calling a
os.system('whoami') in my script for debugging.

When I su www-data at the terminal, I can access /var/foo just fine.

What's even weirder, if I switch the ownership of /var/foo to any of
the other groups (except the cvs and the dbtest one), the script
works!

The only inconsistancy is in dbtest and cvs.

I have attempted to rename them, adjust their ids, pretty much
everything I thought of.

I'm out of ideas.

HELP!

~ Aienthiwan.

| 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.

--
Never forget the halloween documents.
http://www.opensource.org/halloween/
""" Where will Microsoft try to drag you today?
Do you really want to go there?"""

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 <> wrote in message news:<>...
> | 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.