0

I'm trying to predict which files I can delete using unlink().

My understanding so far is that the file must either be writeable to others, or have the same group id or owner id as the executing program.

Are there any other cases? I'm trying to explain how these files are deletable by my program (the program is not running as root nor in the admin group).

drwxrwxr-x  4 root  admin    136 Apr 17 23:53 .
drwxrwxr-x  7 root  admin    238 Jan 27 11:49 ..
-rwxrwxr-x  1 root  admin    560 Jan 27 11:49 info.nib
-rwxrwxr-x  1 root  admin  18399 Jan 27 11:49 keyedobjects.nib

Thanks!

emrosenf
  • 87
  • 5

4 Answers4

3

Actually, it is the permissions of the directory that matter!

Thomas Padron-McCarthy
  • 27,232
  • 8
  • 51
  • 75
1

One more case is when another process still has the file you want to delete, opened. From man page of unlink

EBUSY

The file pathname cannot be unlinked because it is being used by the system or another process; for example, it is a mount point or the NFS client software created it to represent an active but otherwise nameless inode ("NFS silly renamed").

Also note that the process's effective UID should have write access to the directory containing the filepath you want to unlink.

Pavan Manjunath
  • 27,404
  • 12
  • 99
  • 125
  • Here, have a point for being the first place I found why I was getting EBUSY when opening an ordinary file and not using O_EXCL. – Rick Berge Apr 30 '15 at 18:51
1

As others have mentioned, the directory must be writeable by the effective user. However, the file can have extended permissions (ACLs) applied to it that prevent it from being deleted. From the example you show, I think you're using Mac OS, right? There you can use ls -le to display the ACL. The chmod(1) manpage tells you about the various permissions. If you want to query the ACL in your program, you should probably start by reading the acl(3) manpage.

Michael Wild
  • 24,977
  • 3
  • 43
  • 43
  • I believe that this is the correct answer, but when I try to get the acl of the files: `acl_t acl = acl_get_file(path, ACL_TYPE_EXTENDED);`, I get the `EINVAL` errno. – emrosenf Apr 18 '12 at 16:24
  • Also, I cycled through the ancestor directories with `ls -l -a -e -@;cd ..` and the best that I could glean is that one of the ancestor directories has the `com.apple.FinderInfo` attribute. I still can't figure out how this would help me determine whether a file in a directory is unlinkable. – emrosenf Apr 18 '12 at 16:28
0

the directory it resides in should have +w

J-16 SDiZ
  • 26,473
  • 4
  • 65
  • 84