# Problème de permission dans /tmp avec redirection

**URL:** <https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893>\
**Category:** Support Debian\
**Created:** [Avril 24, 2020, 8:21 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893 "2020-04-24T08:21:49Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![nikrou](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/779978/32.png) [@nikrou](https://www.debian-fr.org/u/nikrou)\
**Post date:** [Avril 24, 2020, 8:21 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/1 "2020-04-24T08:21:49Z")

</div>

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 «&nbsp;Permission denied&nbsp;». 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.

---

<div class="post-metadata">

**Author:** ![anon93295908](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b782af/32.png) [@anon93295908](https://www.debian-fr.org/u/anon93295908)\
**Post date:** [Avril 24, 2020, 8:45 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/2 "2020-04-24T08:45:25Z")

</div>

bonjour

Il est peut etre plein ton tmp

---

<div class="post-metadata">

**Author:** ![nikrou](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/779978/32.png) [@nikrou](https://www.debian-fr.org/u/nikrou)\
**Post date:** [Avril 24, 2020, 9:05 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/3 "2020-04-24T09:05:02Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![anon93295908](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b782af/32.png) [@anon93295908](https://www.debian-fr.org/u/anon93295908)\
**Post date:** [Avril 24, 2020, 9:31 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/4 "2020-04-24T09:31:28Z")

</div>

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

voir avec la commande chattr +i  
[lien sur chattr](https://forum.ubuntu-fr.org/viewtopic.php?id=309559)

---

<div class="post-metadata">

**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\
**Post date:** [Avril 24, 2020, 9:49 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/5 "2020-04-24T09:49:23Z")

</div>

Ce serait quand me bine de montrer les retours de :

```nohighlight
df -h

```

et :

```nohighlight
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 @anon93295908, mais cela résulte d’une action volontaire.

---

<div class="post-metadata">

**Author:** ![nikrou](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/779978/32.png) [@nikrou](https://www.debian-fr.org/u/nikrou)\
**Post date:** [Avril 24, 2020, 10:11 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/6 "2020-04-24T10:11:24Z")

</div>

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 «&nbsp;su -&nbsp;». C’est un fichier créé par php.  
Je ne connaissais pas chattr. La commande me renvoie :

`--------------e----- log_2020_04_24`

---

<div class="post-metadata">

**Author:** ![anon93295908](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b782af/32.png) [@anon93295908](https://www.debian-fr.org/u/anon93295908)\
**Post date:** [Avril 24, 2020, 10:45 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/7 "2020-04-24T10:45:25Z")

</div>

> [@nikrou](#):
>
> log\_2020\_04\_24

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

---

<div class="post-metadata">

**Author:** ![PengouinPdt](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pengouinpdt/32/3978_2.png) [@PengouinPdt](https://www.debian-fr.org/u/PengouinPdt)\
**Post date:** [Avril 24, 2020, 12:04 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/8 "2020-04-24T12:04:19Z")

</div>

> [@anon70622873](#):
>
> df -h

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 `-i`pour s’en assurer ! 😛

---

<div class="post-metadata">

**Author:** ![nikrou](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/779978/32.png) [@nikrou](https://www.debian-fr.org/u/nikrou)\
**Post date:** [Avril 24, 2020, 3:12 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/9 "2020-04-24T15:12:47Z")

</div>

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
```

---

<div class="post-metadata">

**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\
**Post date:** [Avril 25, 2020, 3:25 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/10 "2020-04-25T03:25:17Z")

</div>

Bonjour,

> [@nikrou](#):
>
> Je pourrais évidemment utiliser truncate ou rm suivi de touch

A tout hasard, que donne ceci :

```auto
echo | tee /tmp/tonfichier

```

---

<div class="post-metadata">

**Author:** ![nikrou](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/779978/32.png) [@nikrou](https://www.debian-fr.org/u/nikrou)\
**Post date:** [Avril 25, 2020, 6:06 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/11 "2020-04-25T06:06:37Z")

</div>

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

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.

---

<div class="post-metadata">

**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\
**Post date:** [Avril 25, 2020, 7:15 UTC](https://www.debian-fr.org/t/probleme-de-permission-dans-tmp-avec-redirection/81893/12 "2020-04-25T07:15:10Z")

</div>

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.
