0

I'm trying to clean some garbage shared memory files left behind by a service after crashing. The service is run as a system user and a specific group. I'm a member of that group, but can't delete the shared memory. 

$ ls -la /dev/shm
drwxrwxrwt  2 root   root        600 Jun 20 11:18 .
drwxr-xr-x 22 root   root       3680 Jun 19 12:43 ..
-rw-rw-rw-  1 simbot simusers 500032 Jun 20 10:35 Sim_SharedMem_SLM__data_0

$ groups | grep simusers -q && echo member || echo not member
member

$ rm -f /dev/shm/Sim_SharedMem_SLM__data_0 
rm: cannot remove '/dev/shm/Sim_SharedMem_SLM__data_0': Operation not permitted

I have no problems deleting the files as root. I also have no problems deleting the file if I'm the one who runs (and crashes) the process (I'm the user that owns the files).

Reproducing

I think the easiest way to exhibit the problem is to run the process as myself and then change some of the garbage files as if they were owned by the other user.

$ /usr/local/bin/badProcess
^C

$ ls -la /dev/shm
drwxrwxrwt  2 root root     640 Jun 20 11:31 .
drwxr-xr-x 22 root root    3680 Jun 19 12:43 ..
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_0
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_1
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_2
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_3

$ sudo chown simbot          Sim_SharedMem_SLM__data_1
$ sudo chown       :simusers Sim_SharedMem_SLM__data_2
$ sudo chown simbot:simusers Sim_SharedMem_SLM__data_3

$ ls -la /dev/shm
drwxrwxrwt  2 root   root         640 Jun 20 11:31 .
drwxr-xr-x 22 root   root        3680 Jun 19 12:43 ..
-rw-rw-rw-  1 stew   stew      500032 Jun 20 11:31 Sim_SharedMem_SLM__data_0
-rw-rw-rw-  1 simbot stew      500032 Jun 20 11:31 Sim_SharedMem_SLM__data_1
-rw-rw-rw-  1 stew   simusers  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_2
-rw-rw-rw-  1 simbot simusers  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_3

$ rm /dev/shm/*
rm: cannot remove 'Sim_SharedMem_SLM__data_1`': Operation not permitted
rm: cannot remove 'Sim_SharedMem_SLM__data_3`': Operation not permitted

lsattr

Some solutions suggest checking for +a or +i attributes with lsattr. 

$ lsattr Sim_SharedMem_SLM__data_0
lsattr: Inappropriate ioctl for device While reading flags on Sim_SharedMem_SLM__data_0

That happens because those attributes are not supported by tmpfs (which is what this directory is)

$ mount | grep /dev/shm
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)

ACLs

I took a look at the ACL to see if there was anything funny with the parent directory or the file itself. I don't see that we didn't learn from ls I have write permissions to the parent directory

$ getfacl /dev/shm
getfacl: Removing leading '/' from absolute path names
# file: dev/shm
# owner: root
# group: root
# flags: --t
user::rwx
group::rwx
other::rwx

$ getfacl /dev/shm/Sim_SharedMem_SLM__data_0 
getfacl: Removing leading '/' from absolute path names
# file: dev/shm/Sim_SharedMem_SLM__data_0
# owner: simbot
# group: simusers
user::rw-
group::rw-
other::rw-
Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
Stewart
  • 13,677

1 Answers1

3

It's not the file permissions that are of interest when deleting a file, but the permissions of the directory in which the file is residing.

In your case, everyone has write permissions in the directory, but the directory also has the "sticky bit" set (the t at the end of the permission string).

File deletion in such a directory works differently, and you have to be the owner of the file, or the owner of the sticky directory, or be root, to be able to delete the file.

This is from the sticky(8) manual on an OpenBSD system:

STICKY DIRECTORIES

A directory with the ‘sticky bit’ set places restrictions on file deletion: a file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the superuser. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files.

On Ubuntu, the chmod(1) manual has the equivalent information:

RESTRICTED DELETION FLAG OR STICKY BIT

The restricted deletion flag or sticky bit is a single bit, whose interpretation depends on the file type. For directories, it prevents unprivileged users from removing or renaming a file in the directory unless they own the file or the directory; this is called the restricted deletion flag for the directory, and is commonly found on world-writable directories like /tmp. For regular files on some older systems, the bit saves the program's text image on the swap device so it will load more quickly when run; this is called the sticky bit.

Kusalananda
  • 333,661