Problème de permission dans /tmp avec redirection

Support Debian
#1

Bonjour,
j’ai un fichier de log dans /tmp qui appartient à www-data et que j’avais l’habitude de vider en étant root (pas avec sudo) en faisant une redirection :
# > my_logfile

Quelque chose a du changer car depuis quelques temps car désormais j’ai un « Permission denied ». C’est très surprenant d’avoir ce genre de message en étant root !
Cela ne se produit que dans /tmp. SI je créé un autre fichier dans un autre répertoire je n’ai pas le soucis. Le répertoire /tmp est une partition à part, en ext4 mais elle ne semble pas plus particulière que cela.

Si vous voulez plus d’infos ou des retours de commande, n’hésitez pas.
Merci d’avance pour votre aide.

#2

bonjour

Il est peut etre plein ton tmp

#3

Ce n’est malheureusement pas ça. Le répertoire est quasiment vide. Il n’y a que quelques fichiers.

#4

C’est quand tu creer un fichier ou tu utilise le meme fichier

voir avec la commande chattr +i
lien sur chattr

#5

Ce serait quand me bine de montrer les retours de :

df -h

et :

mount | grep ^/

Si une commande passé dans un vrai shell root (obtenu avec su -, ou sudo -i, ou en connexion directe) affiche un « permission denied » sur un fichier c’est que le volume est monté en lecture seule ou qu’il est occupé à 100%. Il y a aussi l’attribut « immutable » évoqué par @cleloup, mais cela résulte d’une action volontaire.

#6

Sortie de df -h :

Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               7,7G       0  7,7G   0% /dev
tmpfs              1,6G    1,7M  1,6G   1% /run
/dev/nvme0n1p2      48G     29G   16G  65% /
tmpfs              7,8G    262M  7,5G   4% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              7,8G       0  7,8G   0% /sys/fs/cgroup
/dev/nvme0n1p1     511M    276K  511M   1% /boot/efi
/dev/nvme0n1p5     9,2G     37M  8,6G   1% /tmp
/dev/nvme0n1p4     229G     77G  140G  36% /var
/dev/nvme0n1p6     174G     61G  105G  37% /home
tmpfs              1,6G    8,0K  1,6G   1% /run/user/1000

sortie de mount | grep ^/ :

/dev/nvme0n1p2 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/nvme0n1p1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/nvme0n1p5 on /tmp type ext4 (rw,relatime)
/dev/nvme0n1p4 on /var type ext4 (rw,relatime)
/dev/nvme0n1p6 on /home type ext4 (rw,relatime)

C’est un shell obtenu avec un « su - ». C’est un fichier créé par php.
Je ne connaissais pas chattr. La commande me renvoie :

--------------e----- log_2020_04_24

#7

que renvoie un ls -l sur ton fichier que tu ne peut pas réinitialiser ?

#8

je dirais même mieux :

df -hi

En effet, même si une partition peut sembler presque vide, il est des situations où les inodes eux sont tous pris, d’où l’ajout de l’option -ipour s’en assurer ! :stuck_out_tongue:

#9

Pour information, je suis en debian unstable et ce comportement est apparu il y a quelques semaines, surement lors d’une mise à jour.

Je n’ai aucun problème pour déplacer/renommer/supprimer ce fichier qui n’appartient pas à root. La seule chose que je ne peux pas faire c’est faire une redirection de l’entrée standard avec null ce qui a pour effet de vider le fichier. Je pourrais évidemment utiliser truncate ou rm suivi de touch. Mais j’ai pris l’habitude de faire comme cela et je trouve cela franchement pratique.

Ce phénomène ne se produit que dans tmp. Ma partition est vide. Et non ce n’est pas un problème d’inode non disponible. Je peux reproduire le problème juste après le reboot. Ma configuration vide tmp au reboot ce qui n’est pas le cas par défaut il me semble.

Mais je n’ai pas d’autre idée. Merci tout de même d’avoir cherché des idées. Si vous en avez d’autres je suis preneur.

La sortie de ls donne ça :

-rw-rw-rw- 1 www-data www-data 0 avril 24 17:02 log_2020_04_24
#10

Bonjour,

A tout hasard, que donne ceci :

echo | tee /tmp/tonfichier
#11

Le echo avec tee me donne aussi un « Permission denied ».

Bon, hasard, je ne sais plus trop comment, j’ai fini par trouver. Le répertoire /tmp avait le sticky bit de positionné . C’est aussi bête que ça. Une chose est sure : ce n’est pas moi qui l’est positionné. Je verrais au prochain reboot si c’est dans la conf du système ce qui expliquerait que c’est apparu récemment.

En tout cas merci à tous pour votre aide.

#12

Alors là il faut que tu expliques.
Le dossier /tmp a effectivement des droits particuliers : tout le monde peut y lire et y écrire et il a le sticky bit. C’est comme ça sur tous les systèmes.
Je rappelle que le sticky bit positionné sur un dossier fait que seul le propriétaire du fichier, du dossier ou root peut supprimer ou renommer ce fichier.
Donc a priori ce n’est pas cela qui empêche de vider ton fichier. J’ai d’ailleurs tenté l’expérience et la commande >/tmp/truc exécutée par root fonctionne parfaitement quel que soit le propriétaire du fichier.

1 J'aime