WebDAV - Page 1

je savais pas trop ou mettre ça, mais bon.

Bref je suis en train de bricoler un accès webDAV à mon serveur (sur SSL, pas de souci d'authentification)

Y a t il un moyen rapide pour que les fichiers créés par le serveur appartiennent à l'utilisateur que je veux? parce que là, J'ai remarqué que les fichiers créés par Apache appartiennent à l'utilisateur du serveur moi je voudrais qu'ils appartiennent à l'utilisateur unix qui a accès au dossier apache!

  <Directory /vhosts/https/www.unsads.com/dav>
                order deny,allow
                deny from all
        </Directory>

#ce dossier est un lien vers ailleurs
        <Directory /vhosts/https/www.unsads.com/dav/squalyl> 
                Options Indexes FollowSymLinks
                AllowOverride none
                order allow,deny
                allow from all
                DAV On
                AuthType Basic
                AuthName "DAV repository: squalyl"
                AuthUserFile /backed/web/auth/svn.htpasswd
                Require valid-user
                Require user squalyl
        </Directory>

hmm en fait webDAV c'est pas vraiment fait pour monter un accès générique à des fichiers

voir http://www.webdav.org/mod_dav/install.html

Seul root peut changer le propriétaire d'un fichier, non ?

meme remarque... ca appartiendra forcement à l'utilisateur d'apache vu que c'est lui qui crée les fichiers...

oui en fait c'est pas faisable.

Bref, ça permettra d'avoir un dossier perso, mais pas un accès complet à un $HOME.

Il y a deux moyens : un cron (sous root) qui force toutes les 2 minutes les autorisations et les possesseurs des fichiers du ~ au possesseur dudit dossier (c'est ce que fait par défaut Mandriva en mode "pas moyen que tu fasses un pet de travers, ton serveur est tellement protégé que toi même tu ne peux rien faire"), ou un script php (ou n'importe quoi d'autre) (soit automatique, soit manuel) qui exécute une commande système en sudo (par contre, c'est vraiment pas conseillé au niveau sécuritaire - mais il y a des cas où c'est indispensable).

Mais si tu changes le proprio, tu ne pourras plus effacer les fichiers en passant par webdav, non ? ou alors il faut faire tourner apache en root (tiens, du coup c'est le même pb pour les serveurs ftp, non ? )

effectivement, joli idée le crontab, sauf qu'on peut plus virer les fichiers
autant faire un chmod o+w.
faire tourner apache en root, nan merci

les serveurs ftp sont pas chrootés et exécutés par un fork() avec l'util kivabien? je ferais ça, moi, si je devais en faire un.

squalyl (./8) :
les serveurs ftp sont pas chrootés et exécutés par un fork() avec l'util kivabien? je ferais ça, moi, si je devais en faire un.

Ok, donc ça serait le mod_webdav d'apache qui serait moisi vu qu'il ne peut pas faire la même chose ? (c'est bien possible, apache n'a sûrement pas été conçu pour faire du webdav)

voila, sans doute

dans ma config j'aimerais bien un dav-setuid machin et dav-setgid machin
mais en effet ça demande peut être que le serveur soit lancé en root, donc bof.

tiens, ça a l'air de concerner ton problème : http://ask.slashdot.org/article.pl?sid=03/07/25/0045222

wé, donc en gros c'est bien ce que j'avais suspecté. Bon ce sera scp alors

Flanker (./9) :

squalyl (./8) :
les serveurs ftp sont pas chrootés et exécutés par un fork() avec l'util kivabien? je ferais ça, moi, si je devais en faire un.

Ok, donc ça serait le mod_webdav d'apache qui serait moisi vu qu'il ne peut pas faire la même chose ? (c'est bien possible, apache n'a sûrement pas été conçu pour faire du webdav)

=> En général, pour les serveurs ftp, tu as un serveur maitre qui accepte les connexions et forke un processus à chaque connexion. Lui tourne en root.
=> Le processus forké réalise la phase d'authentification de l'utilisateur, puis ce chroot lui même et enfin se supprime les accès root avec setuid/setgid.

Dans tous les cas pour faire ce genre de choses il te faut un maître qui conserve tous les accès. Donc pas faisable avec apache ^^

y a pas de maître avec apache ?

c'est variable, et certainement pas configurable, vu que tu peux choisir un partage en threads, processus, etc...

Sous Apache, si mes souvenirs sont bons, il y a un ensemble de processus à l'écoute du port (le système attribue les connexions à ceux qui sont en attente d'un accept()). Les processus réalisent le traitement eux-même sans forker, et tournent de base avec les droits de l'utilisateur apache.

Les droits root sont lachés dès l'initialisation en fait (juste après le bind sur le port 80). D'ailleurs, si tu mets ton apache en écoute sur un port > 1024, il n'a pas besoin d'être exécuté en tant que root.

Il y a quand-même ça: http://bluecoara.net/item24/cat5.html. Mais ça implique d'exécuter Apache en root.

you have to compile and configure Apache2 with -DBIG_SECURITY_HOLE option.

Mort de rire le nom de l'option
Si avec ça le mec dit encore qu'il savait pas ...

La solution m'aurait intéressé, mais comme mon serveur est sous windows c'est mort de toute façon ^^

En meme temps il doit y avoir des "serveur" webdav qui sont capable de gerer les droits de maniere correct... (apple le fait bien avec l'iDisk par exemple qui utilise WebDAV)

bah ué mais ça me ferait chier d'avoir deux serveurs sur le port 80
on peut s'en sortir avec un mod_proxy ptet... genre l'URL http blabla m'envoie sur un autre serveur...

spectras (./16) :
Sous Apache, si mes souvenirs sont bons, il y a un ensemble de processus à l'écoute du port (le système attribue les connexions à ceux qui sont en attente d'un accept()). Les processus réalisent le traitement eux-même sans forker, et tournent de base avec les droits de l'utilisateur apache.

C'est marrant mais sur certains vieux serveurs, on a un httpd qui se forke à la demande (et ça nous pose d'ailleurs pas mal de soucis... certains forks restent à l'état de zombie en bloquant des sessions).

C'est possible, c'est comme ça qu'étaient faits les serveurs traditionnellement. Seulement ça pose problème avec des serveurs acceptant des charges importantes.
Tu peux encore forcer apache à travailler comme ça en jouant sur sa configuration (ou pire en le lançant avec inetd), mais c'est pas recommandé.

spectras (./23) :
(ou pire en le lançant avec inetd)

Tiens, je me demande si ce n'est pas comme ça qu'il est configuré... mais bon, c'est une blackbox (on attend qu'elle meure pour la changer, pour l'instant on évite de trop y toucher)