IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Serveurs (Apache, IIS,...) Discussion :

Droits par défaut d'un fichier déposé sous Unix via Webdav


Sujet :

Serveurs (Apache, IIS,...)

  1. #1
    Llo
    Llo est déconnecté
    Membre à l'essai
    Inscrit en
    Janvier 2005
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 16
    Points : 12
    Points
    12
    Par défaut Droits par défaut d'un fichier déposé sous Unix via Webdav
    Bonjour,

    Je rencontre actuellement un problème de gestion des droits Unix de fichiers déposés par Webdav. Le serveur web utilisé est Sun One Web Server.

    Voici les manipulations que je fais :
    - Création d'un fichier manuellement sous Windows.
    - Dépôt manuel du fichier sous Unix via l'explorateur Windows grâce à un favori réseau Webdav.
    - Récupération du fichier sous Unix.
    Lorsque je dépose un fichier de cette manière, le fichier se retrouve systématiquement avec des droits à 644 côté Unix. Or, pour les besoins d'une application, les droits doivent être positionnés à 664.

    Je ne peux pas utiliser de cron car le dépôt des fichiers et le traitement sur ces fichiers sont faits manuellement. il y a donc un risque d'erreur si le traitement est lancé entre deux passages du cron. Il me faut donc absolument trouver comment appliquer systématiquement les bons droits à chaque fichier déposé.

    J'ai d'abord pensé à modifier le mask de /etc/profile avec : "umask 002".
    Lorsque que je crée directement un fichier sous Unix, celui-ci a bien les droits attendus (664). Par contre, lorsque je dépose un fichier via Webdav, les droits sont à 644 malgré le mask.
    Même en modifiant le .profile de l'utilisateur, le dépôt par Webdav remet les droits à 644.

    Je me suis ensuite tourné vers les droits décrits dans les ACL mais j'ai l'impression qu'ils définissent essentiellement les droits d'accès aux fichiers (en relation avec LDAP) et non pas leur masque de droits lors du dépôt. Je ne maîtrise pas du tout les ACL donc si quelqu'un peut me faire mentir, je ne suis pas contre.

    Il semble que ce soit bien le dépôt des fichiers par Webdav qui fasse appel à un paramétrage restrictif des droits mais impossible de trouver à quel niveau.

    Je commence à avoir fait le tour de mes maigres connaissances sur le sujet ... Toute information ou aide est donc la bienvenue.

    Merci de votre aide.

  2. #2
    Rédacteur
    Avatar de _Mac_
    Profil pro
    Inscrit en
    Août 2005
    Messages
    9 601
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 9 601
    Points : 12 977
    Points
    12 977
    Par défaut
    Citation Envoyé par Llo Voir le message
    J'ai d'abord pensé à modifier le mask de /etc/profile avec : "umask 002".
    Lorsque que je crée directement un fichier sous Unix, celui-ci a bien les droits attendus (664). Par contre, lorsque je dépose un fichier via Webdav, les droits sont à 644 malgré le mask.
    Même en modifiant le .profile de l'utilisateur, le dépôt par Webdav remet les droits à 644.
    Quand tu as fait ces manipulations, tu as bien redémarré ton serveur Web avec le bon utilisateur qui possédait le bon umask ? Dans la conf de Sun One, précises-tu un utilisateur système à utiliser lorsqu'il monte les services (équivalent de la directive User d'Apache) ? Si oui, si tu peux te connecter avec cet utilisateur, vérifie que son umask est correct.

    Du détail, du détail, du détail !!!
    Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute

  3. #3
    Llo
    Llo est déconnecté
    Membre à l'essai
    Inscrit en
    Janvier 2005
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 16
    Points : 12
    Points
    12
    Par défaut
    Bonjour _Mac_,

    Merci pour la rapidité de ta réponse.

    Pour essayer de préciser le contexte, voici quelques infos complémentaires :
    - Le serveur héberge plusieurs applications.
    - Chaque application a son propre filesystem et son propre compte admin.
    - La console d'administration est gérée par root.

    Quand tu as fait ces manipulations, tu as bien redémarré ton serveur Web avec le bon utilisateur qui possédait le bon umask ?
    J'ai retesté la modification du umask au niveau d'une application en redémarrant le serveur de l'application concernée. C'est avec root que je redémarre les applications.
    Les droits d'un fichier déposé sont toujours en 644 malgré le fait que le umask est bien à 002 sur l'appli testée.

    J'ai également mis le umask à 002 au niveau root et relancé l'application ainsi que l'appli d'administration (au cas où ça aurait une influence). Toujours pas concluant...

    J'ai également "ouvert les vannes" au niveau des ACL en donnant tous les droits à tout le monde sur les répertoires de l'application. Ca n'a rien changé non plus.

    D'après toi, la solution tournerait effectivement autours de umask?

  4. #4
    Rédacteur
    Avatar de _Mac_
    Profil pro
    Inscrit en
    Août 2005
    Messages
    9 601
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 9 601
    Points : 12 977
    Points
    12 977
    Par défaut
    Je dirais que oui car j'ai déjà eu ce pb si je me souviens bien, mais c'était avec un autre soft. Pourquoi tu démarres ton appli avec root ? C'est pas très sécurisé. Mais là n'est pas le sujet : quand l'appli est démarrée et que tu fais un ps, quel utilisateur système est indiqué pour l'application qui gère WebDAV ? C'est toujours root ? N'y aurait-il pas tout bêtement un paramètre du serveur WebDAV qui contient le umask à utiliser pour la création des fichiers ?

    Du détail, du détail, du détail !!!
    Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute

  5. #5
    Llo
    Llo est déconnecté
    Membre à l'essai
    Inscrit en
    Janvier 2005
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 16
    Points : 12
    Points
    12
    Par défaut
    Merci _Mac_ pour ton aide.

    L'utilisateur responsable du protocole Webdav est root. L'utilisation de Webdav est encapsulée dans l'administration Sun One Webserver. La seule fonctionnalité de Webdav paramétrable dans la console d'administration est l'activation/désactivation.
    Par contre, lorsqu'un utilisateur dépose un fichier via Webdav, c'est l'utilisateur admin de l'appli qui est sollicité.

    N'y aurait-il pas tout bêtement un paramètre du serveur WebDAV qui contient le umask à utiliser pour la création des fichiers ?
    Là est toute la question et c'est bien ça que je cherche. Le problème c'est que je ne trouve aucune info à ce sujet.
    J'ai beau fouillé dans l'administration du serveur, impossible de trouver un quelconque paramètre qui pourrait faire ça. Idem dans les fichiers de conf...

    Sinon, j'ai découvert l'existence du "sticky bit" qui, si mon faible niveau d'anglais me suffit à comprendre, permet de définir les droits d'un fichier nouvellement créé à partir des droits du répertoire parent. J'ai fait des essais dans ce sens en déposant un fichier dans un répertoire modifié par
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    chmod -R g+s nom_repertoire
    mais toujours le même problème.

    Liens vers des explications du sticky bit :
    http://wiki.dreamhost.com/Unix_File_...sions_Cookbook
    http://wiki.dreamhost.com/Unix_File_Permissions
    http://wiki.dreamhost.com/Security

  6. #6
    Rédacteur
    Avatar de _Mac_
    Profil pro
    Inscrit en
    Août 2005
    Messages
    9 601
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 9 601
    Points : 12 977
    Points
    12 977
    Par défaut
    Le sticky bit, c'est surtout pour l'exécution : si tu peux exécuter le programme, tout se passe comme si ton groupe primaire ou toi-même (l'utilisateur système) étaient ceux du fichier. Si tu regardes bien, le s se met à la place du x, donc par exemple si on a la trace suivante :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    -rwxr-s---   1 root     system 19746336 Jul 13  2005 programme
    tu peux exécuter le programme et ton groupe primaire sera considéré être system. Ce truc est hyper dangereux sur les programmes dont le propriétaire est root, car tu l'exécutes et hop, on croit que tu es root.

    Pour ton problème, dans l'absolu, je ne vois qu'un script batch qui passe et qui fait un chmod, en attendant d'avoir trouvé mieux.

    Mais avant cela, un truc important, toujours sur la piste du umask : mettre un umask dans un .profile n'est pas nécessairement suffisant car rien ne t'indique que le fichier .profile sera pris en compte juste avant d'effectuer l'action. En effet, .profile est un script spécifique à ksh (et quelques autres shell) : un autre shell n'en tiendra pas compte. Ce qu'il faut, c'est définir le umask à un très bas niveau de manière à ce qu'il soit pris en compte quelque soit le moyen utilisé pour exécuter une commande.

    Du détail, du détail, du détail !!!
    Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute

  7. #7
    Llo
    Llo est déconnecté
    Membre à l'essai
    Inscrit en
    Janvier 2005
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 16
    Points : 12
    Points
    12
    Par défaut
    Merci pour l'explication du sticky bit. Je pense que je peux rayer cette piste aussi du coup... J'en apprends des choses en ce moment, mais rien qui me conduise à résoudre mon problème.

    Effectivement, j'avais pensé également à faire un batch mais l'utilisateur final n'est pas habilité à lancer des scripts unix en direct. Ca impliquerait donc de lui créer une interface web pour qu'il puisse lancer son batch.

    Concernant le umask, j'en suis rendu à ne plus avoir de cheveux sur la tête à force de me les arracher...
    Voici un petit extrait du ps -aef pour voir les process (désolé, on ne voit pas la fin des lignes). J'ai simplifié les chemins et modifié les identifiants pour plus de lisibilité. "app" correspond au code de l'application utilisée et à son file system. "appadm" est l'utilisateur admin de cette application.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    root 00002     1  0 10:20:14 ?        0:00 ./webservd-wdog -r /racine/webserver -d /racine/webserver/https-admserv/config -n
    root 00003 00002  0 10:20:14 ?        0:00 webservd -r /racine/webserver -d /racine/webserver/https-admserv/config -n https-
    root 00004 00003  0 10:20:14 ?        0:07 webservd -r /racine/webserver -d /racine/webserver/https-admserv/config -n https-
    root 00014     1  0 15:34:34 ?        0:00 ./webservd-wdog -r /racine/webserver -d /racine/webserver/https-app/config -n htt
    root 00015 00014  0 15:34:34 ?        0:01 webservd -r /racine/webserver -d /racine/webserver/https-app/config -n https-app
    appadm 00016 00015  0 15:34:34 ?        0:27 webservd -r /racine/webserver -d /racine/webserver/https-app/config -n https-app
    D'après ce que je crois avoir compris :
    - Le serveur héberge n applications.
    - Chaque application possède son propre filesystem.
    - L'application d'administration qui permet notamment d'activer/désactiver le Webdav est gérée par root.
    - Chaque application cliente possède un utilisateur admin.
    - Cependant, l'arrêt/démarrage des applications clientes est fait par root en appelant des scripts propres à chaque application.
    - Pour déposer un fichier dans un répertoire d'une application cliente, l'utilisateur se connecte via le favori réseau de l'explorateur windows avec son user LDAP. Cela lui donne accès à une partie de l'arborescence du filesystem de l'application.
    - La relation entre l'utilisateur LDAP et l'arborescence de dépôt de fichiers est faite grâce aux ACL.

    En décortiquant tout ça, je ne parviens toujours pas à trouver où peut être défini un umask qui serait utilisé par Webdav.
    Je pense que je vais devoir faire intervenir un expert extérieur et je vous ferai part de la solution (si elle existe).

  8. #8
    Rédacteur
    Avatar de _Mac_
    Profil pro
    Inscrit en
    Août 2005
    Messages
    9 601
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 9 601
    Points : 12 977
    Points
    12 977
    Par défaut
    Citation Envoyé par Llo Voir le message
    Effectivement, j'avais pensé également à faire un batch mais l'utilisateur final n'est pas habilité à lancer des scripts unix en direct. Ca impliquerait donc de lui créer une interface web pour qu'il puisse lancer son batch.
    Non, pas du tout, faut faire un script lancé toutes les minutes par exemple par cron, ça sera beaucoup plus simple à gérer.

    C'est quel OS ? Solaris j'imagine ?

    Du détail, du détail, du détail !!!
    Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute

  9. #9
    Llo
    Llo est déconnecté
    Membre à l'essai
    Inscrit en
    Janvier 2005
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 16
    Points : 12
    Points
    12
    Par défaut
    Oui c'est bien Solaris.

    Pour le cron, comme je le disais dans mon tout premier message : l'utilisateur dépose ses fichiers manuellement et lance le traitement les manipulant manuellement également. Donc s'il fait ces opérations entre 2 passages du cron, le traitement va planter.

  10. #10
    Rédacteur
    Avatar de _Mac_
    Profil pro
    Inscrit en
    Août 2005
    Messages
    9 601
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 9 601
    Points : 12 977
    Points
    12 977
    Par défaut
    Pardon, j'avais oublié

    Comme il lance son traitement, l'utilisateur ? Y a pas moyen de faire un chmod au début du programme qu'il lance, s'il faut en passant par sudo ?

    Sinon, t'as déjà essayé de modifier le umask avant de lancer le serveur, mais as-tu essayé de forcer le umask dans la commande de lancement du serveur ? Si le script de lancement est un script shell, juste avant de lancer le serveur, peut-être peux-tu faire le umask qui va bien ???

    EDIT : la solution définitive (mais sûrement trop) pourrait venir de là : http://www.science.uva.nl/pub/solari...is2/Q3.53.html. Le umask par défaut du système est défini dans /etc/default/init : s'il n'y a que cette appli qui tourne sur le serveur, ça peut valoir le coup de changer ce fichier. Faut rebooter le serveur pour qu'il le prenne en compte, je pense. Sinon, essaie la solution proposée avec le umask.sh

    Du détail, du détail, du détail !!!
    Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute

  11. #11
    Llo
    Llo est déconnecté
    Membre à l'essai
    Inscrit en
    Janvier 2005
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 16
    Points : 12
    Points
    12
    Par défaut
    Citation Envoyé par _Mac_ Voir le message
    Pardon, j'avais oublié
    Ne t'excuse pas. Si tu savais comme ça devient brouillon dans ma tête, tu n'aurais pas honte d'en oublier des bouts.

    Citation Envoyé par _Mac_ Voir le message
    Comme il lance son traitement, l'utilisateur ? Y a pas moyen de faire un chmod au début du programme qu'il lance, s'il faut en passant par sudo ?
    L'utilisateur lance son traitement via une application web qui se trouve sur un serveur s1. Une servlet récupère certains paramètres (arborescence à traiter, serveur où manipuler les fichiers, ...) et appelle les services d'un composant RMI Java qui se trouve sur un serveur s2 (s2 pouvant être égal à s1). Pour faire simple, ce composant copie une arborescence A du serveur s2 vers une arborescence B de ce même serveur s2. En fin de traitement, il exécute un script shell pour réaffecter le bon propriétaire et les bons droits des répertoires et fichiers copiés.
    J'ai bien essayé d'exécuter un script shell en début du traitement du composant RMI mais ses droits sont limités et il ne peut donc pas agir sur les fichiers.
    Je pense qu'en demandant l'exécution de ce script par l'application appelant le composant RMI, on pourrait s'en sortir.
    Mais on entre là dans des considérations politiques et budgétaires : modifier l'application appelante ou demander des habilitations par sudo demanderait trop de temps et serait trop couteux (impact sur de nombreuses applications puisque le traitement est mutualisé).

    Citation Envoyé par _Mac_ Voir le message
    as-tu essayé de forcer le umask dans la commande de lancement du serveur ?
    Oui cette solution a été testée. Le résultat est toujours le même.

    Citation Envoyé par _Mac_ Voir le message
    EDIT : la solution définitive (mais sûrement trop) pourrait venir de là : http://www.science.uva.nl/pub/solari...is2/Q3.53.html. Le umask par défaut du système est défini dans /etc/default/init : s'il n'y a que cette appli qui tourne sur le serveur, ça peut valoir le coup de changer ce fichier. Faut rebooter le serveur pour qu'il le prenne en compte, je pense. Sinon, essaie la solution proposée avec le umask.sh
    Merci pour cette nouvelle piste. Je vais testé ça demain matin à tête reposée. Effectivement, le problème ne concerne qu'une application installée sur un serveur dédié (est-ce une bonne utilisation de "dédié" là? ). Je dois donc pouvoir manipuler cette donnée sans risque.

    Encore merci de consacrer autant de temps à mon problème.

    EDIT : Après relecture de ton lien de signature, je remplacerais bien "dédié" par "spécifique" ou "qui lui est alloué" ou "qui lui est réservé"... Pas facile de se décider en fait...

  12. #12
    Llo
    Llo est déconnecté
    Membre à l'essai
    Inscrit en
    Janvier 2005
    Messages
    16
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 16
    Points : 12
    Points
    12
    Par défaut
    Bonjour,

    Voici quelques nouvelles de mon problème.

    J'ai testé le changement de la valeur CMASK tel que proposé par Mac. Aucune amélioration de comportement de mes fichiers malades.

    Après discussion avec un expert Sun, celui-ci m'a proposé de rajouter le Umask dans le fichier magnus.conf de l'instance concernée.

    Il semble que les processus externes utilisent un umask par défaut qui n'est pas visible dans les fichiers de configuration. On ne peut donc que le "surcharger" en déclarant le umask qui nous convient dans le fichier approprié. La difficulté étant de trouver dans quel fichier on doit intervenir...

    Après saisie du Umask souhaité dans le fichier magnus.conf et redémarrage du serveur, les tests effectués sont concluants. C'est le bon umask qui est appliqué!

    Par contre, à savoir :
    - Le Umask déclaré dans le fichier magnus.conf ne se comporte pas comme le umask manipulé en ligne de commande.
    D'habitude, la commande s'écrit "umask 007" pour obtenir des droits à 770.
    Là, dans le fichier magnus.conf, la commande s'écrit "Umask 0770" pour obtenir ces mêmes droits (le "U" majuscule a son importance).
    - Le Umask de magnus.conf n'agit pas sur les droits des répertoires pour les versions de Web Server inférieures à la 6.1 SP8.

    Le sujet est clos.

    Encore un grand merci à Mac pour son soutien moral.

  13. #13
    Rédacteur
    Avatar de _Mac_
    Profil pro
    Inscrit en
    Août 2005
    Messages
    9 601
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2005
    Messages : 9 601
    Points : 12 977
    Points
    12 977
    Par défaut
    Cool, ravi d'apprendre que tu as trouvé une solution

    Du détail, du détail, du détail !!!
    Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [chmod] Remettre les droits par défaut
    Par Haze. dans le forum Shell et commandes GNU
    Réponses: 7
    Dernier message: 06/09/2017, 21h33
  2. Fichier Policy, RuntimePermission, droits par défaut
    Par woods dans le forum Sécurité
    Réponses: 0
    Dernier message: 22/04/2009, 18h16
  3. Extension par défaut d'un fichier généré par un spool
    Par lcloatre dans le forum Sql*Plus
    Réponses: 1
    Dernier message: 10/10/2007, 16h30
  4. Obtenir le chemin par défaut pour les fichiers de données.
    Par Cpas2latarte dans le forum MS SQL Server
    Réponses: 4
    Dernier message: 27/08/2007, 17h38
  5. Valeur par défaut de champs d'un sous-formulaire
    Par snoopy69 dans le forum Access
    Réponses: 2
    Dernier message: 21/10/2005, 08h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo