Forum général.général Partager des folders d'un serveur entre utilisateurs locaux/distants sans faille

Posté par  . Licence CC By‑SA.
Étiquettes :
2
8
sept.
2018

Admettons que sur une machine type NAS sous debian on dispose d'un dossier Coucou.
Ce dossier Coucou doit être utilisé (RW) par l'utilisateur www-data, l'utilisateur www-data-backup et l'utilisateur www-data-remote utilisé par d'autres machines pour monter le dossier.

Comment partager le plus proprement le dossier ? (chaque users devant pouvoir lire, modifier, créer, supprimer et ce sans passer par un chmod 776 -R)

J'ai déjà testé de mettre les utilisateurs dans les mêmes groupes via usermod -g user1 user2 mais ca marche quand ca veut.

  • # GRoupes

    Posté par  . Évalué à 3. Dernière modification le 08/09/18 à 18:22.

    Il te faut utiliser les groupes :
    1. tu crées un groupe coucou dont tous tes utilisateurs sont membres.
    2. tu donnes les droits au groupe.
    3. tu changes le mode de création par défaut des fichiers pour ces utilisateurs afin qu'il donne le droit d'écrire au groupe.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: GRoupes

      Posté par  . Évalué à 1. Dernière modification le 08/09/18 à 19:51.

      Je bloque sur le point 3.

      La pour le test j'ai usermod -G user1,user2,user3 userX pour chaque utilisateur et j'ai encore des permission denied en série.

      • [^] # Re: GRoupes

        Posté par  . Évalué à 1. Dernière modification le 08/09/18 à 20:00.

        Est-ce que tu as mis un sticky bit sur le dossier qui contient les fichiers ?
        Si le dossier s'appelle coucou et est censé avoir les permissions 770:

        chmod 2770 coucou/

        ça permettra que tous les dossiers et sous dossiers créés dans ce dossier appartiennent au groupe.

        Les vrais naviguent en -42

        • [^] # Re: GRoupes

          Posté par  . Évalué à 1. Dernière modification le 08/09/18 à 21:34.

          Lorsque www-data-remote crée un dossier, les fichiers se retrouvent avec comme droit

          drwxr-sr-x 1 www-data-remote www-data
          

          Se qui provoque un permission denied pour www-data.

        • [^] # Re: GRoupes

          Posté par  (site Web personnel) . Évalué à 4.

          J'en profite pour détailler un peu comment cela fonctionne :

          • on connaît les fameux r, w, x pour chaque utilisateur (u), groupe (g) et autre (o) ;
          • il y a également le bit setuid, qui correspond à u+s ;
          • mais aussi le bit setgid, qui correspond à g+s ;
          • et enfin le bit sticky, qui correspond à o+t (ou +t).

          Les trois derniers ont comme poids respectifs 4, 2 et 1, d'où le 2 en préfixe des permissions usuelles.

          Le bit setgid, c'est ce que j'appelle le mode « collaboratif », et c'est ce qui permet de créer des fichiers/répertoires dans le même groupe que le répertoire parent plutôt que d'avoir le comportement par défaut, qui est de mettre les nouveaux items dans… le groupe principal de l'utilisateur en question.

          Vu les besoins décrits, c'est effectivement probablement suffisant (modulo le problème d'umask). Alternativement, il est possible de positionner des ACL au niveau du système de fichiers (si les outils sont installés — paquet acl sous Debian — et si l'option est activée sur le système de fichiers — acl dans /etc/fstab) si on n'a pas la possibilité de régler le problème d'umask. Mais cela sous-entend de savoir reconnaître que des ACL sont positionnées, et comment les consulter/modifier (chacl, getfacl, setfacl). Flexibilité++ mais complexité++… ;)

          Debian Consultant @ DEBAMAX

          • [^] # Re: GRoupes

            Posté par  . Évalué à 1. Dernière modification le 10/09/18 à 13:24.

            Merci pour tes détails :)

            Vu les besoins décrits, c'est effectivement probablement suffisant (modulo le problème d'umask). Alternativement, il est possible de positionner des ACL au niveau du système de fichiers (si les outils sont installés — paquet acl sous Debian — et si l'option est activée sur le système de fichiers — acl dans /etc/fstab) si on n'a pas la possibilité de régler le problème d'umask. Mais cela sous-entend de savoir reconnaître que des ACL sont positionnées, et comment les consulter/modifier (chacl, getfacl, setfacl). Flexibilité++ mais complexité++… ;)

            Je n'ai pas encore testé cette piste qui me fait un peu peur (de break mes services).
            Y a-t-il un risque à installer les paquets nécéssaire ou bien rien ne se passe tant que je ne vais pas moi-même éditer le /etc/fstab ?

            Quand j'aurai enfin réussi a résoudre le soucis de ce thread, j'ouvrirai un tuto sur la création de cluster web histoire que les suivants évitent cette galère :)

      • [^] # Re: GRoupes

        Posté par  . Évalué à 3.

        tu peux configurer le umask (masque de permission pour la création de fichiers)

        $ umask
        0022
        $ touch tst_umask
        $ umask 0002
        $ touch tst_umask_1
        $ ls -l tst_umask*
        -rw-r--r-- 1 gab gab 0 Sep  8 20:01 tst_umask
        -rw-rw-r-- 1 gab gab 0 Sep  8 20:01 tst_umask_1
        • [^] # Re: GRoupes

          Posté par  . Évalué à 1. Dernière modification le 08/09/18 à 21:56.

          L'équivalent du chmod 770 est donc umask 007, sauf qu'il agira au niveau utilisateur ? (en se basant sur wiki)
          Un peu flippant la commande ^ ^ (si ça foire ça va provoquer une cascade ^ ^ )

          • [^] # Re: GRoupes

            Posté par  . Évalué à 3.

            non, ce n'est pas la même chose. umask définit le masque de permission qui va être appliqué pour tous les nouveaux fichiers. Tant que tu ne crées pas de nouveaux fichiers, l'effet d'umask est nul. D'autre part, quand tu modifies ton umask, ça n'a aucune incidence sur les fichiers déjà créés. Je pense que pour toi, c'est intéressant de combiner les deux. umask pour que les nouveaux fichiers soient créés avec le droit en écriture pour le groupe, et chmod pour que les fichiers déjà existants obtiennent ce droit.

            Soit-dit en passant, chmod 770, c'est un peu violent. Tu peux faire plus fin. C'est possible de ne rajouter que le droit en écriture pour le groupe sans toucher aux autres permissions (avec chmod g+w)

            $ umask 
            0022
            $ touch fichier1
            $ ls -l fichier1 
            -rw-r--r-- 1 gab gab 0 Sep  8 22:39 fichier1
            $ umask 0002
            $ touch fichier2
            $ ls -l fichier*
            -rw-r--r-- 1 gab gab 0 Sep  8 22:39 fichier1
            -rw-rw-r-- 1 gab gab 0 Sep  8 22:40 fichier2
            $ chmod g+w fichier1 
            $ ls -l fichier*
            -rw-rw-r-- 1 gab gab 0 Sep  8 22:39 fichier1
            -rw-rw-r-- 1 gab gab 0 Sep  8 22:40 fichier2

            Note qu'après la modif du umask, les droits de fichier1 n'ont pas été modifié.

            La configuration d'umask se fait souvent dans le .profile.

            • [^] # Re: GRoupes

              Posté par  . Évalué à 1. Dernière modification le 09/09/18 à 00:16.

              umask est définitif ou sa respawn a chaque reboot? (je pense pas qu'il y aille de .profile pour les utilisateurs sans home)

              Je pense tester avec umask u+rwx,g+rwx,o-rwx je retirerai l’exécution si elle n'est pas nécessaire pour les scripts php.

              Merci pour les infos :)

              • [^] # Re: GRoupes

                Posté par  . Évalué à 3.

                Ça se comporte comme les variables d'environnement (même si ça n'en est pas). Si tu modifies le umask dans un processus, tous les processus fils hériteront de cet umask, mais pas les autres processus.

                Pour tes utilisateurs qui sont des serveurs web, ça vaut le coup de regarder dans la doc ce qui est préconisé pour la config de l'umask.

                • [^] # Re: GRoupes

                  Posté par  . Évalué à 1. Dernière modification le 10/09/18 à 12:48.

                  Alors j'ai tenté de forcer l'umask pour www-data en éditant /etc/init.d/apache2 et /etc/apache2/envvars afin d'y ajouter umask 0007 (j'ai aussi testé avec 007).

                  root@machine:/# ls -l /media/ssd/folder/from_www-data.test
                  -rw-r--r-- 1 www-data www-data   0 Sep 10 12:47 /media/ssd/folder/from_www-data.test
                  

                  A noter que hier pendant un moment j'ai eu des fichiers créé en drwxrws--- mais dont les fichiers créé par www-data dedans se retrouvaient a nouveau avec rw-r--r--.

                  Pour SSHFS, j'ai ajouté umask 0007 dans le /home/www-data-remote/.profile, /etc/profile et ai édité /etc/ssh/sshd_config

                  afin de faire remplacer

                  Subsystem sftp /usr/lib/openssh/sftp-server
                  

                  par

                  Subsystem sftp /usr/lib/openssh/sftp-server -u 0007
                  

                  Résultat:

                  -rw-r----- 1 www-data-remote www-data   0 Sep 10 12:43 from_sshfs.test
                  

                  Mais rien n'y fait, après avoir eu très temporairement un comportement qui semblait proche de celui escompté, je n'ai de nouveau plus que des fichiers en rw-r--r--.

                  • [^] # Re: GRoupes

                    Posté par  . Évalué à 3. Dernière modification le 10/09/18 à 13:26.

                    je viens de faire quelques tests avec sftp, et, en dehors du fait qu'il faut redémarrer le serveur ssh après la modif de la config, j'attire ton attention sur le fait que sftp ne rajoute pas le droit w sur le groupe. Il applique juste le umask. Donc si le droit w n'est pas présent pour le groupe sur le fichier avant le transfert par sftp, il n'y sera toujours pas après.

                    Plus globalement, vu que tu as trois sources potentielles de nouveaux fichiers dans tes répertoires, ça sera plus simple si tu découpes ton problème en trois questions distinctes, et que tu debug ta config en les prenant une par une.

                    • [^] # Re: GRoupes

                      Posté par  . Évalué à 1. Dernière modification le 10/09/18 à 13:36.

                      Plus globalement, vu que tu as trois sources potentielles de nouveaux fichiers dans tes répertoires, ça sera plus simple si tu découpes ton problème en trois questions distinctes, et que tu debug ta config en les prenant une par une.

                      C'est déjà se que je tente :)
                      Actuellement je tente de partager un dossier pour www-data et www-data-remote (dédié a sshfs), le troisième user (www-data-backup) se débrouille pour le moment avec sa rustine (cron qui chmod/chown toutes les deux minutes).
                      Précisément voici l'origine du problème : [Retour] Test - Migration Zoneminder Server from X64 to ARM without break

                      Donc si le droit w n'est pas présent pour le groupe sur le fichier avant le transfert par sftp, il n'y sera toujours pas après.

                      Tu parles du fichiers local avant d'être envoyé sur le remote storage? Pourtant il me semble avoir lu que l'umask côté client, pour sshfs, n'était qu'une simulation de fuse qui n'avait rien a voir avec la réalité.
                      Toujours est-il que j'ai tenté

                      mount /media/storage -o umask=0007
                      

                      Mais cela n'avait l'air d'avoir aucun effet.

                      • [^] # Re: GRoupes

                        Posté par  . Évalué à 3.

                        j'ai peut-être répondu à côté. J'ai vu passer sftp, j'ai répondu sftp :)

                        Mais sur le fond, c'est la même question. Est-ce que tes fichiers sont bien créés avec le droit w pour le groupe, et sshfs, pour une raison encore à trouver, le zappe au moment du transfert, ou est-ce que sshfs n'y est pour rien ?

                        (c'est facile à tester. un fichier local avec les bons droits et une copie sur le montage en sshfs)

                        • [^] # Re: GRoupes

                          Posté par  . Évalué à 1. Dernière modification le 10/09/18 à 13:58.

                          Ta remarque semble juste d'après ce test :

                          Sur le client sshfs

                          root@ClusterOne:/home/# cd /tmp
                          
                          root@ClusterOne:/tmp# touch from_sshfs.test
                          
                          root@ClusterOne:/tmp# ls -l from_sshfs.test 
                          -rw-r--r-- 1 root root 0 sep 10 13:46 from_sshfs.test
                          
                          root@ClusterOne:/tmp# chmod 770 from_sshfs.test 
                          
                          root@ClusterOne:/tmp# ls -l from_sshfs.test 
                          -rwxrwx--- 1 root root 0 sep 10 13:46 from_sshfs.test
                          
                          root@v:/tmp# mv ./from_sshfs.test /media/storage_SSHFS/
                          mv: failed to preserve ownership for '/media/storage_SSHFS/from_sshfs.test': Permission denied
                          
                          root@ClusterOne:/tmp# touch /media/storage_SSHFS/from_sshfs_without_chmod.test
                          
                          root@ClusterOne:/tmp# ls -l /media/storage_SSHFS/
                          total 12
                          -rwxrwx--- 1     1002 www-data   0 sep 10 13:48 from_sshfs.test
                          -rwxrwx--- 1     1002 www-data   0 sep 10 13:50 from_sshfs_without_chmod.test

                          (on remarquera que fuse signale des droits identiques)

                          Sur le serveur :

                          root@machine:/home/# ls -l /media/ssd/folder/
                          -rwxrwx--- 1 www-data-sshfs www-data   0 Sep 10 13:48 from_sshfs.test
                          -rw-r----- 1 www-data-sshfs www-data   0 Sep 10 13:50 from_sshfs_without_chmod.test

                          A noter que mon script de montage a déjà -o umask=0007, comment je peux forcer ce droit (c'est root qui s'occupe du montage)?

                          • [^] # Re: GRoupes

                            Posté par  . Évalué à 3.

                            sur ClusterOne, d'après les droits sur from_sshfs.test créé dans /tmp, le umask de root sur ClusterOne ne donne pas le droit gw. Qu'est ce que ça donne si tu changes le umask de root avant de faire le touch sur la partition sshfs ?

                            • [^] # Re: GRoupes

                              Posté par  . Évalué à 1. Dernière modification le 10/09/18 à 14:30.

                              Qu'est ce que ça donne si tu changes le umask de root avant de faire le touch sur la partition sshfs ?

                              Les permissions semblent bonne.

                              Sur le client

                              root@ClusterOne:/tmp# umask 007
                              
                              root@ClusterOne:/tmp# touch /media/storage_SSHFS/from_sshfs_without_chmod.test
                              
                              root@ClusterOne:/tmp# mkdir /media/storage_SSHFS/test
                              
                              root@ClusterOne:/tmp# touch /media/storage_SSHFS/test/from_sshfs_without_chmod.test
                              
                              

                              Sur le serveur

                              root@machine:/# ls -l /media/ssd/folder/
                              total 0
                              -rw-rw---- 1 www-data-sshfs www-data   0 Sep 10 14:25 from_sshfs_without_chmod.test
                              drwxrws--- 1 www-data-sshfs www-data  58 Sep 10 14:28 test
                              
                              root@machine:/# ls -l /media/ssd/folder/test
                              total 0
                              -rw-rw---- 1 www-data-sshfs www-data 0 Sep 10 14:28 from_sshfs_without_chmod.test
                              

                              J'ai tenté de forcer le umask sur le client en modifiant /etc/profile pour ajouter umask 007 mais même après reboot cela ne change rien.

                              • [^] # Re: GRoupes

                                Posté par  . Évalué à 3.

                                ok. Si je comprends bien ce que je vois, sshfs transfert correctement les permissions à partir de ClusterOne ver le serveur. Pour les fichiers créés sur la partition sshfs de ClusterOne, les fichiers sont listés avec les droits 770, mais c'est peut-être trompeur.

                                J'ai l'impression que ton utilisateur local ne crée pas les fichiers avec les bons droits sur ClusterOne.

                                Si tu as assez d'espace disque sur ClusterOne, tu peux tenter démonter la partition sshfs et vérifier avec quels droits ton utilisateur créé les fichiers.

                                • [^] # Re: GRoupes

                                  Posté par  . Évalué à 1. Dernière modification le 10/09/18 à 14:54.

                                  Ca avance grâce a toi, merci :)

                                  Si tu as assez d'espace disque sur ClusterOne, tu peux tenter démonter la partition sshfs et vérifier avec quels droits ton utilisateur créé les fichiers.

                                  Je dois passer par la ligne de commande, si je démonte la partition ZoneMinder ne retrouve plus ses jeunes.

                                  Sur le client

                                  root@ClusterOne:/tmp# sudo -u www-data touch /media/storage_SSHFS/from_sshfs_by_www-data_user.test
                                  
                                  root@ClusterOne:/tmp# ls -l /media/storage_SSHFS/
                                  total 12
                                  -rw-r----- 1     1002 www-data   0 sep 10 14:41 from_sshfs_by_www-data_user.test
                                  
                                  root@ClusterOne:/tmp# sudo -u www-data touch /var/www/html/local_file_from_www-data.test
                                  
                                  root@ClusterOne:/tmp# ls -l /var/www/html/local_file_from_www-data.test
                                  -rw-r----- 1 www-data www-data 0 sep 10 14:43 /var/www/html/local_file_from_www-data.test
                                  

                                  Sur le serveur

                                  root@machine:/# ls -l /media/ssd/folder/
                                  total 0
                                  -rw-r----- 1 www-data-sshfs www-data   0 Sep 10 14:41 from_sshfs_by_www-data_user.test
                                  

                                  Il semble donc falloir aussi forcer le umask de www-data sur le client (j'ai déjà tenté vainement sur le serveur).
                                  C'est fort contre-intuitif.

                                  • [^] # Re: GRoupes

                                    Posté par  . Évalué à 3.

                                    Ca avance grâce a toi, merci :)

                                    cool :)

                                    Elle semble donc falloir aussi forcer le umask de www-data sur le client (j'ai déjà tenté vainement sur le serveur).

                                    oui, mais je n'appellerais pas ça du forçage, c'est modifier les permissions par défaut pour les nouveaux fichiers. Il y a toujours un umask.

                                    C'est fort contre-intuitif.

                                    c'est parce que tu continues de penser à umask comme un équivalent à chmod, alors que ce n'est pas ça. Tu as du voir sur le net que le système applique un XOR entre les permissions du fichier et l'umask. L'application de umask ne peut aboutir, au maximum, qu'à un retrait de permissions, jamais à un ajout. C'est un masque (il peut masquer certaines permissions).

                                    Quand tu changes l'umask en 0002 (resp. 0007), tu dis simplement que tu acceptes les droits rwxrwxr.x (resp. rwxrwx…), pas que tu les imposes. Donc si ton fichier n'a pas le droit gw quand il est créé, aucune configuration de umask ne va jamais le rajouter.

                                    • [^] # Re: GRoupes

                                      Posté par  . Évalué à 1. Dernière modification le 10/09/18 à 15:28.

                                      oui, mais je n'appellerais pas ça du forçage, c'est modifier les permissions par défaut pour les nouveaux fichiers. Il y a toujours un umask.

                                      Je suppose donc qu'il est obligatoire de passer par les ACL expliquées brièvement plus haut?

                                      Donc si je résume :
                                      -umask côté serveur pour "ne pas interdire" des permissions
                                      -acl côté serveur pour forcer les bonnes permissions
                                      -acl côté client pour forcer les bonnes permissions
                                      ?

                                      • [^] # Re: GRoupes

                                        Posté par  . Évalué à 1.

                                        non ! je disais juste qu'à partir du moment ou umask est de la configuration, le terme "forçage" est discutable :)

                                        Normalement, des umask bien réglés partout, ça devrait fonctionner.

                                        Côté serveur, le bon umask fait que tes droits ne seront pas tronqués lors du transfert par ssh (dans ton montage sshfs).
                                        Et côté clients, l'umask s'applique lors de la création des fichiers pour éventuellement retirer certaines permissions des permissions par défaut du système pour les fichiers et répertoires.

                                        Là, c'est perturbant parce qu'on utilise umask côté serveur dans un rôle étendu par rapport à son rôle initial. Au départ, umask servait juste à définir les permissions par défaut pour un utilisateur en appliquant un XOR entre les permissions par défaut du système et le umask de l'utilisateur. (Les permissions par défaut du système étant rwxxrwxrwx pour les répertoires, et rw.rw.rw. pour les fichiers)

                                        • [^] # Re: GRoupes

                                          Posté par  . Évalué à 1. Dernière modification le 10/09/18 à 15:59.

                                          Vu que tantôt ca avait l'air d'avoir l'effet escompté en lancant umask 007 avant de créer des fichiers : je tente de forcer l'umask de www-data afin de refaire le test.
                                          Mais actuellement PAS MOYEN.
                                          J'ai édité /etc/profile, /etc/init.d/apache2 et /etc/apache2/envvars puis reboot, rien n'y fait 😭

                                          • [^] # Re: GRoupes

                                            Posté par  . Évalué à 3. Dernière modification le 10/09/18 à 16:30.

                                            hmmm … tu parlais d'un souci potentiel avec fuse. On en est peut-être arrivé là. À tout hasard, est-ce que les gid pour le groupe www-data sont les même sur toutes les machines ?

                                            Par rapport à ton test , qu'est-ce que ça donne si tu fais:

                                            sudo -u www-data -c "umask 0007; touch /media/storage_SSHFS/from_sshfs_by_www-data_user.test"
                                            • [^] # Re: GRoupes

                                              Posté par  . Évalué à 1. Dernière modification le 10/09/18 à 17:30.

                                              Alors il semblerait que je me trompais ici.

                                              Je pense peut-être avoir réussi à régler le www-data sur ClusterOne. J'ai répliqué l'exacte même modifs sur le serveurs. Mais … Permission Denied.

                                              Il ne faut pas tester les droits d'apache2 via ligne de commande mais en appelant une page web. (source)
                                              J'ai donc créé un script (inspiré d'un recup dans le lien précédent)

                                              <?php
                                              $path = "/media/storage_SSHFS/";
                                              mkdir( $path . "test" );
                                              if ($fp = fopen($path . "/test/" . time() . '.txt', 'w')) {
                                                fwrite($fp, 'This is a simple test.');
                                                fclose($fp);
                                                echo "done";
                                              } else {
                                                echo "error - cannot create file";
                                              }
                                              ?>
                                              

                                              (il crée un dossier test dans $path et un fichier time.txt dedans)

                                              Résultat sur le client :

                                              root@ClusterOne:/# ls -l /media/storage_SSHFS/
                                              total 20
                                              -rwxrwx--- 1     1002 www-data  22 sep 10 17:08 1536592133.txt
                                              drwxrwx--- 1     1002 www-data  28 sep 10 17:16 test
                                              
                                              root@andromede1:/home/voxpopuli# ls -l /media/storage_SSHFS/test/
                                              total 4
                                              -rwxrwx--- 1 1002 www-data 22 sep 10 17:16 1536592563.txt
                                              

                                              Résultat sur le serveur :

                                              root@machine:/# ls -l /media/ssd/folder/
                                              total 4
                                              -rw-rw---- 1 www-data-sshfs www-data  22 Sep 10 17:08 1536592133.txt
                                              drwxrws--- 1 www-data-sshfs www-data  28 Sep 10 17:16 test
                                              
                                              root@machine:/# ls -l /media/ssd/folder/test/
                                              total 4
                                              -rw-rw---- 1 www-data-sshfs www-data 22 Sep 10 17:16 1536592563.txt
                                              

                                              Ca avait l'air parfait et donc :
                                              J'ai testé en lançant zoneminder et en changeant une camera de serveur (et donc l'enregistrement est passé de www-data a www-data-sshfs) et les "Can't mkdir events/16/18/09/10/17/04: Permission denied" ré-apparaissent.

                                              Dans les fichiers je peux voir ce genre de choses :

                                              root@serveur:/# ls -l /media/ssd/folder/events/16/18/09/10/
                                              total 0
                                              drwxrws--- 1 www-data www-data 24 Sep 10 14:50 14
                                              drwxrws--- 1 www-data www-data 28 Sep 10 15:50 15
                                              drwxrws--- 1 www-data www-data 36 Sep 10 16:50 16
                                              drwxr-sr-x 1 www-data www-data  8 Sep 10 17:02 17
                                              

                                              (j'avais chown www-data:www-data et chmod 2770 tout les folders avant le test, le folder 17 a probablement été créé après le chmod/chown)

                                            • [^] # Re: GRoupes

                                              Posté par  . Évalué à 1. Dernière modification le 10/09/18 à 17:57.

                                              Par rapport à ton test , qu'est-ce que ça donne si tu fais:

                                              sudo -u www-data -c "umask 0007; touch /media/storage_SSHFS/from_sshfs_by_www-data_user.test"
                                              

                                              Ta commande renvoie sudo: umask: command not found

                                              • [^] # Re: GRoupes

                                                Posté par  . Évalué à 1.

                                                je pense que c'est le code de zone minder. En tout cas, j'ai récupéré le code source de la branche master de leur version libre. Dans src/zm_event.cpp, il y a plusieurs :

                                                    if ( mkdir(path, 0755) ) {

                                                Donc, à moins que je n'ai pas localisé le bon endroit dans le code source, ce n'est pas un paramétrage de l'utilisateur, c'est le code qui force directement ces permissions.

                                                Plusieurs options possibles :
                                                - faire une remontée de bug et espérer que le dév en tiennent compte assez vite
                                                - proposer un patch (mais ça nécessite probablement de discuter avec eux pour voir comment ils veulent le gérer. Perso, je leur suggérerais de laisser le umask à la discrétion de l'utilisateur en utilisant 0777, ou de le mettre en paramètre de l'appli)
                                                - recompiler une version à toi locale avec un patch
                                                - utiliser des trucs genre inotify pour aller changer les permissions à la volée (ce qui devraient bien marcher tant qu'il n'y a pas trop de trafic mais qui, dans l'absolu, n'est pas 100% fiable)
                                                - avoir un seul utilisateur plutôt que trois
                                                - … si quelqu'un a une bonne idée, c'est le moment ! :)

                                                • [^] # Re: GRoupes

                                                  Posté par  . Évalué à 3.

                                                  ou il y a peut-être une solution à base d'ACL, mais je ne m'en suis jamais servi. Je ne sais pas bien ce que ça peut faire. à creuser

                                                • [^] # Re: GRoupes

                                                  Posté par  . Évalué à 1. Dernière modification le 11/09/18 à 02:07.

                                                  Donc, à moins que je n'ai pas localisé le bon endroit dans le code source, ce n'est pas un paramétrage de l'utilisateur, c'est le code qui force directement ces permissions.

                                                  Ca ne m'avait même pas traversé l'esprit. Il est plus que probable que le soucis viennent de là.
                                                  Je viens de tenter de changer l'utilisateur de ZoneMinder mais ca amène pas mal de problèmes/bugs. Donc le prochain test de demain sera de monter localement (127.0.0.1) le remote storage via SSHFS. Ainsi ZM continuera d'utiliser www-data et le storage son propre user.

                                                  PS : excuse pour les -1 sur deux de tes msg, mais les boutons pertinents/inutile c'est une horreur avec les écrans tactiles ^ ^

Suivre le flux des commentaires

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