Tengo una instancia de Ubuntu 20.04.x en AWS que mostró un comportamiento muy inesperado.
Tengo un archivo en /tmp:
root@ip-10-0-1-145:/tmp# ls -l api_requests_2023-08-23.log
-rw-r--r-- 1 www-data www-data 47450 Aug 23 19:04 api_requests_2023-08-23.log
Intenté truncarlo, por rootlo que FAILED!!!
root@ip-10-0-1-145:/tmp# truncate -s 0 api_requests_2023-08-23.log
truncate: cannot open 'api_requests_2023-08-23.log' for writing: Permission denied
Intenté strace para comprobar dónde estaba el fallo, lo que me dio:
root@ip-10-0-1-145:/tmp# strace -e trace=file truncate -s 0 api_requests_2023-08-23.log
execve("/usr/bin/truncate", ["truncate", "-s", "0", "api_requests_2023-08-23.log"], 0x7ffcaa0ab958 /* 16 vars */) = 0
...
openat(AT_FDCWD, "api_requests_2023-08-23.log", O_WRONLY|O_CREAT|O_NONBLOCK, 0666) = -1 EACCES (Permission denied)
...
truncate: cannot open 'api_requests_2023-08-23.log' for writing: Permission denied
...
+++ exited with 1 +++
Dado que la temperatura tiene el bit adhesivo configurado como de costumbre:
root@ip-10-0-1-145:/tmp# ls -ld
drwxrwxrwt 4 root root 12288 Sep 12 09:11 .
Intenté truncar el archivo usando su propietario:
root@ip-10-0-1-145:/tmp# sudo -u www-data truncate -s 0 api_requests_2023-08-23.log
root@ip-10-0-1-145:/tmp# ls -lh api_requests_2023-08-23.log
-rw-r--r-- 1 www-data www-data 0 Sep 12 09:13 api_requests_2023-08-23.log
¡¡¡ El truncatedueño trabajó!!! (por lo que esto no se debe a problemas del sistema de archivos; el sistema de archivos es local, en disco, ext4, montado con los valores predeterminados).
Este comportamiento para bits adhesivos en directorios esdefinidocomo **'only owner or root'** para todas las operaciones.
¿Cómo se rootrestringió la apertura del archivo para escribir ( >api_requests_2023-08-23.logtambién falló el trucado)?