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 :oops: ... Toute information ou aide est donc la bienvenue.

Merci de votre aide.

Citation:

---

Envoyé par Llo

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.

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.

Citation:

---

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?

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 ?

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é.

Citation:

---

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:

---

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

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:

---

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

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:

---

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).

Citation:

---

Envoyé par Llo

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 ?

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.

Pardon, j'avais oublié :oops:

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 :roll:

Citation:

---

Envoyé par _Mac_

Pardon, j'avais oublié :oops:

---

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. :roll:

Citation:

---

Envoyé par _Mac_

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_

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. :cry:

Citation:

---

Envoyé par _Mac_

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 :roll:

---

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... ;)

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é!:yaisse2:

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. ;)

Cool, ravi d'apprendre que tu as trouvé une solution :king: