Dango signal can't delete directory

35 views
Skip to first unread message

Stodge

unread,
Nov 6, 2014, 10:08:55 AM11/6/14
to django...@googlegroups.com
I have a separate daemon running as root that generates cached image tiles per user for a map. For now it creates them under /tmp/tile_cache. When it creates a new tile cache it changes the UID and GID to the apache user (on Fedora) and also gives everyone access to the directory, e.g. permissions are rwxrwxrwx.

My Django app runs under mod_wsgi using Apache. I have a Django view triggers a signal and the signal is supposed to delete a cache for the requesting user. However, the signal uses os.path.isdir and refuses to "see" the directory. os.path.exists fails to see the directory as well. Attempts to delete the directory using shutils.rmtree also fail because I assume it can't for some reason stat the directory.

I have no idea why the signal can't delete the directory - can anyone point anything obvious out? Thanks

Tom Evans

unread,
Nov 6, 2014, 10:55:03 AM11/6/14
to django...@googlegroups.com
/tmp always has the sticky bit set, which means only the owner of a
file can remove it, regardless of permissions.

Cheers

Tom

Tom Evans

unread,
Nov 6, 2014, 10:56:39 AM11/6/14
to django...@googlegroups.com
On Thu, Nov 6, 2014 at 3:54 PM, Tom Evans <teva...@googlemail.com> wrote:
> On Thu, Nov 6, 2014 at 3:08 PM, Stodge <sto...@gmail.com> wrote:
>> I have a separate daemon running as root that generates cached image tiles
>> per user for a map. For now it creates them under /tmp/tile_cache. When it
>> creates a new tile cache it changes the UID and GID to the apache user (on
>> Fedora)

Oops, missed that bit!

Can you run stat as the user running the deletion for each component
in the path up to /tmp.

Eg, if it is /tmp/tile_cache/1234/567:

stat /tmp
stat /tmp/tile_cache
stat /tmp/tile_cache/1234

etc

Cheers

Tom

Bruno Barcarol Guimarães

unread,
Nov 6, 2014, 10:59:35 AM11/6/14
to django...@googlegroups.com
> os.path.exists fails to see the directory as well.

This is strange. Are you sure you are referencing the right directory (it
happens...)? The only other reason I can think of is your program or apache (or
both) running with mount namepsace on /tmp.


That said:

> When it creates a new tile cache it changes the UID and GID to the apache user (on Fedora) and also gives everyone access to the directory, e.g. permissions are rwxrwxrwx.

Remember you need write permission on the *parent* directory to remove a file
inside it. E.g.: to remove `a/b` you need write permission on `a` (permissions
on `b` don't matter, in this case).

Stodge

unread,
Nov 6, 2014, 11:02:15 AM11/6/14
to django...@googlegroups.com
I'll see if the python code under Apache can stat /tmp. Thanks.

Stodge

unread,
Nov 6, 2014, 11:03:44 AM11/6/14
to django...@googlegroups.com
I'm debug printing the directory I'm trying to delete, so I'm sure it's correct. But you raise a valid point!

I also change permissions and ownership of /tmp/tile_cache.

Thanks.

Stodge

unread,
Nov 6, 2014, 11:11:57 AM11/6/14
to django...@googlegroups.com
I added:

    try:
        mode = os.stat(path).st_mode
        print(str(S_ISDIR(mode)))
    except Exception, e:
        print("Error stating tile cache %s" % str(e))
 
Which gives:

Error stating tile cache [Errno 2] No such file or directory: '/tmp/tile_cache/mike'

But ls -al /tmp/tile_cache shows the "mike" directory clearly exists. So I'm assuming the Python code under Apache can't stat the directory.

ls /tmp/tile_cache -al 
total 0
drwxr-xr-x  3 apache apache   60 Nov  6 11:07 .
drwxrwxrwt 58 root   root   1380 Nov  6 11:07 ..
drwxrwxrwx  2 apache apache  860 Nov  6 11:07 mike

Oh but I just noticed that the total is '0'. Weird.

Stodge

unread,
Nov 6, 2014, 11:16:57 AM11/6/14
to django...@googlegroups.com
Tom, you might be right about the sticky bit. If I store the tile cache elsewhere, the signal can successfully delete it.
Reply all
Reply to author
Forward
0 new messages