Utiliser des dossiers sans risque c'est impossible, pour moi, à cause du fait que les systèmes POSIX ne permettent pas de verrouiller un dossier pour écriture par un seul processus (les «verrous» reposent sur l'idée que tout le monde respecte les conventions)…
Du coup, à part créer un utilisateur pour chaque service, puis créer un dossier dans /tmp ou /dev/shm pour chaque utilisateur (qui ne soit inscriptible que par l'utilisateur) et prier pour que personne ne joue avec le compte root, il ne me semble pas vraiment possible d'utiliser un dossier «sans risque». Et c'est encore pire avec systemd, puisque, la dernière fois que j'ai regardé, tous les processus fils de systemd-init (du projet systemd) avaient un UID de 0… je me trompe peut-être.
D'un autre côté, c'était sur Debian, et je commence à penser sérieusement que Debian n'est pas aussi robuste que sa réputation ne tends à le faire croire.
Ha l'attaque classique sur systemd, tout est pire avec lui même si tout le monde qui a eu à regarder pour savoir objectivement quoi soutenir pour la maintenance collective (bref, qu'ils vont devoir se taper le taf) a trouvé que c'était le "moins pire" justement…
Il faut lire le lien ces problématiques sont évoquées et il y a des solutions comme utiliser memfd_create ou l'option d'open O_TMPFILE qui ne passe pas par le système de fichier mais utilise le RAM.
Et justement avec systemd il y a PrivateTmp qui donne un /tmp et /var/tmp dédié pour le service en utilisant les namespaces.
Posté par GnunuX (site web personnel) .
Évalué à 7.
Dernière modification le 21 février 2019 à 21:21.
Et c'est encore pire avec systemd, puisque, la dernière fois que j'ai regardé, tous les processus fils de systemd-init (du projet systemd) avaient un UID de 0…
# Vraiment?
Posté par freem . Évalué à -4.
Utiliser des dossiers sans risque c'est impossible, pour moi, à cause du fait que les systèmes POSIX ne permettent pas de verrouiller un dossier pour écriture par un seul processus (les «verrous» reposent sur l'idée que tout le monde respecte les conventions)…
Du coup, à part créer un utilisateur pour chaque service, puis créer un dossier dans /tmp ou /dev/shm pour chaque utilisateur (qui ne soit inscriptible que par l'utilisateur) et prier pour que personne ne joue avec le compte root, il ne me semble pas vraiment possible d'utiliser un dossier «sans risque». Et c'est encore pire avec systemd, puisque, la dernière fois que j'ai regardé, tous les processus fils de systemd-init (du projet systemd) avaient un UID de 0… je me trompe peut-être.
D'un autre côté, c'était sur Debian, et je commence à penser sérieusement que Debian n'est pas aussi robuste que sa réputation ne tends à le faire croire.
[^] # Re: Vraiment?
Posté par Zenitram (site web personnel) . Évalué à 5.
Ha l'attaque classique sur systemd, tout est pire avec lui même si tout le monde qui a eu à regarder pour savoir objectivement quoi soutenir pour la maintenance collective (bref, qu'ils vont devoir se taper le taf) a trouvé que c'était le "moins pire" justement…
Ça faisait longtemps (ou pas).
[^] # Re: Vraiment?
Posté par millman . Évalué à 5.
Il faut lire le lien ces problématiques sont évoquées et il y a des solutions comme utiliser memfd_create ou l'option d'open O_TMPFILE qui ne passe pas par le système de fichier mais utilise le RAM.
Et justement avec systemd il y a PrivateTmp qui donne un /tmp et /var/tmp dédié pour le service en utilisant les namespaces.
[^] # Re: Vraiment?
Posté par GnunuX (site web personnel) . Évalué à 7. Dernière modification le 21 février 2019 à 21:21.
Regardons …
Ok …
Tu crois ?
# pour vos scripts
Posté par kna . Évalué à 3.
Pour vos scripts shell, utilisez mktemp(1) : https://www.netmeister.org/blog/mktemp.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.