Discussion :

[Llo]

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.

[_Mac_]

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.

[Llo]

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?

[_Mac_]

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 ?

[Llo]

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

[_Mac_]

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.