目录具有777权限，但如果它是root或用户所有，则行为不同

Question

This is a bizarre thing that a coworker just discovered. As the title, /var/tmp has 777 permission. We have a library that we must use (but do not have source access to, disappointing) which when used creates a temp file to do its work (no idea what it is actually doing with that file) and then immediately deletes it. At least, that's what's supposed to happen. When /var/tmp is root:root owned, the files are never deleted, never closed. If we change owner to user:user it works perfectly, files are created and deleted faster than they can be detected. This only occurs on his Ubuntu 14.04 32bit machine. We also have an Ubuntu 12.04 64bit, Debian 7 32 and 64 bit, CentOS6 32 and 64 bit, and a CentOS5 32bit and this behavior is not seen on any of those others, they all work exactly as intended no matter who owns /var/tmp

This is a problem because after about 1000 times of this library doing its thing the process hits the file limit and refuses to continue.

Can anyone think of a situation where a directory could have 777 permission (albeit owned by root), allowing a user process to create a file, but then not be able to delete that file?

Thanks a lot!

edit: Process is run as the user that /var/tmp is chowned to in order to make it work.

$ ls -ltrd /var/tmp/*
drwxr-xr-x 2 user user 4096 Oct  7  2013 /var/tmp/audacity-user
drwx------ 2 root root 4096 Nov 28  2013 /var/tmp/kdecache-root
drwx------ 3 user user 4096 Apr 25 18:07 /var/tmp/kdecache-user
-rw------- 1 root root    3 Jul  3 11:07 /var/tmp/zhanceqDC3256C54D298DEE.dat
-rw------- 1 user user    3 Jul  3 14:25 /var/tmp/homjeaocAADD02BC6EDB687D.tmp

I'm trying to get my coworker to give a similar directory listing while the problem is happening but he stepped out suddenly and may not be back until tomorrow.

Answer 1

Nevermind, the problem has been uncovered. Don't know the full sequence of events but the problem was the "zhanceqDC3256C54D298DEE.dat" file. Apparently this library also creates this file and presumably deletes it: when the directory was owned by root, it could not delete the file even with 777 permission. When the directory is owned by user it can. The other way to fix it was to simply sudo rm the file and let the library create it itself. This process is only ever meant to be run as a user, never as root, but just to test it I ran it as root (and a third user) and in each case it creates a different file with the pertinent user ownership (some kind of user tied guid I guess), so HOW this guy managed to get into this situation will probably remain forever unknown.