CGI Python user/group permission weirdness

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Aienthiwan

    CGI Python user/group permission weirdness

    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('whoa mi') 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.
  • Samuel Walters

    #2
    Re: CGI Python user/group permission weirdness

    | Aienthiwan said |
    [color=blue]
    > Ok - this one's a baffling one.[/color]
    <chop>[color=blue]
    > I have confirmed that it's the www-data user by calling a
    > os.system('whoa mi') in my script for debugging.[/color]
    <chop>[color=blue]
    > The only inconsistancy is in dbtest and cvs.[/color]

    Have you tried os.system('grou ps') 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.

    """ Where will Microsoft try to drag you today?
    Do you really want to go there?"""

    Comment

    • Aienthiwan

      #3
      Re: CGI Python user/group permission weirdness

      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_usene t@yahoo.com> wrote in message news:<pan.2004. 01.18.10.21.20. 719254@yahoo.co m>...[color=blue]
      > | Aienthiwan said |
      >[color=green]
      > > Ok - this one's a baffling one.[/color]
      > <chop>[color=green]
      > > I have confirmed that it's the www-data user by calling a
      > > os.system('whoa mi') in my script for debugging.[/color]
      > <chop>[color=green]
      > > The only inconsistancy is in dbtest and cvs.[/color]
      >
      > Have you tried os.system('grou ps') 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.[/color]
      [color=blue]
      > 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.[/color]

      Comment

      Working...