• # Vraiment?

    Posté par . Évalué à -4 (+2/-8).

    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 (page perso) . Évalué à 6 (+5/-1).

      Et c'est encore pire avec systemd

      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 . Évalué à 5 (+5/-0).

      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 (page perso) . Évalué à 7 (+5/-0). Dernière modification le 21/02/19 à 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…

      Regardons …

      [root@localhost ~]# ps -e -o ppid:1,user,cmd:200|grep ^"1 "|grep systemd
      1 root     /usr/lib/systemd/systemd-journald
      1 root     /usr/lib/systemd/systemd-udevd
      1 systemd+ /usr/lib/systemd/systemd-timesyncd
      1 systemd+ /usr/lib/systemd/systemd-resolved
      1 root     /usr/lib/systemd/systemd-logind
      1 dbus     /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
      1 root     /usr/lib/systemd/systemd-machined
      1 gnunux   /usr/lib/systemd/systemd --user

      Ok …

      je me trompe peut-être

      Tu crois ?

  • # pour vos scripts

    Posté par . Évalué à 3 (+1/-0).

    Pour vos scripts shell, utilisez mktemp(1) : https://www.netmeister.org/blog/mktemp.html

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.