Existe-t-il un serveur webdav multi-utilisateurs disponible pour Linux?


9

Je cherche à désactiver complètement mon service SMBA et à le remplacer par un service WebDav.

Jusqu'à présent, toutes les recherches sur Google m'ont indiqué l'utilisation d'Apache / Webdav. C'est proche de ce dont j'ai besoin mais pour autant que je le lise, Apache doit avoir accès aux fichiers de mon utilisateur et pire; s'il crée un fichier, le nouveau fichier appartiendra à Apache (et non à l'utilisateur). Notez que la possession de fichiers avec la propriété et les autorisations Unix correctes est une exigence car certains utilisateurs ont un accès SSH direct.

Je cherche donc tout simplement un moyen de faire fonctionner Apache / Webdav "correctement" avec des utilisateurs multiples (c'est-à-dire de changer l'utilisateur unix en utilisateur connecté avant d'essayer de servir le fichier ) ou de trouver une alternative complète à Apache / Webdav.

Jusqu'à présent, les recherches n'ont rien révélé.


Comme webdav est basé sur le protocole HTTP, je dirais qu'il n'existe que sous la forme d'un serveur HTTP. Et si vous trouvez un produit qui offre webdav, trhey en offrira généralement plus
Kiwy

Il semble que la dernière version de MPM ITK soit prometteuse. mpm-itk.sesse.net Je vais essayer avec ça et voir si AssignUserIDExpracceptera l'utilisateur connecté. Il se peut que cela ne AssignUserIDse déclenche pas avant que l'utilisateur ne s'authentifie.
Philip Couling

Il existe des serveurs webdav autonomes comme code.google.com/p/opendav ou des bibliothèques comme PyWebDAV qui ne nécessitent pas Apache.
Jan

@jan Cela peut s'avérer être la meilleure réponse. Apache est déjà en cours d'exécution sur le serveur et webdav devrait être un sous-répertoire sur le site, mais je peux le configurer en tant que proxy et utiliser le SSL d'Apache pour fournir le cryptage.
Philip Couling du

1
Doit être déplacé vers Software Recommendations.SE .
William Edwards

Réponses:


2

Si vous avez le nom d'utilisateur et / ou l'uid, vous pouvez le faire avec nginx + lua + luarocks ljsyscall

Sur un système Debian, configuré comme:

apt-get -y install nginx libnginx-mod-http-dav-ext libnginx-mod-http-lua luarocks
luarocks install ljsyscall

Et nginx a configuré la manière suivante:

user  root;
worker_processes  1;

load_module modules/ngx_http_dav_ext_module.so;
load_module modules/ndk_http_module.so;
load_module modules/ngx_http_lua_module.so;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    sendfile        on;
    keepalive_timeout  65;
    gzip  on;

    server {
        listen      80;
        listen [::]:80;

        location / {
            rewrite ^ http://$host$request_uri?; # permanent;
        }
    }

    server {
        listen      443           ssl http2;
        listen [::]:443           ssl http2;

        ssl                       on;    
        # [ SSL Sections Omitted ]

        # Set the maximum size of uploads
        client_max_body_size 200m;

        # Default is 60, May need to be increased for very large uploads
        client_body_timeout 120s; 

        # other configs
        location /webdav/ {
            autoindex              on;
            alias                  /data/www/;
            client_body_temp_path  /data/client_temp;

            dav_methods PUT DELETE MKCOL COPY MOVE;
            dav_ext_methods PROPFIND OPTIONS;

            create_full_put_path   on;
            # Not sure if you want to tweak this
            # dav_access             group:rw  all:r;

            # Let's assume you have an auth subrequest that can set X-UID
            auth_request  /auth
            auth_request_set $auth_status $upstream_status;
            auth_request_set $saved_remote_user $upstream_http_REMOTE_USER;
            auth_request_set $saved_remote_uid $upstream_http_X_UID;

            # Per-Request Impersonation
            access_by_lua_block {
                # Boilerplate because ljsyscall doesn't have setfsuid implemented directly
                local syscall_api = require 'syscall'
                local ffi = require "ffi"
                local nr = require("syscall.linux.nr")
                local sys = nr.SYS
                local uint = ffi.typeof("unsigned int")
                local syscall_long = ffi.C.syscall -- returns long
                local function syscall(...) return tonumber(syscall_long(...)) end 
                local function setfsuid(id) return syscall(sys.setfsuid, uint(id)) end
                -- If you only have ngx.var.saved_remote_user, install luaposix and do this ...
                -- local pwd = require 'posix.pwd'
                -- local new_uid = pwd.getpwnam(ngx.saved_remote_user).pw_uid
                local new_uid = tonumber(ngx.var.saved_remote_uid)
                ngx.log(ngx.NOTICE, "[Impersonating User #" .. new_uid .. "]")
                local previous = setfsuid(new_uid)
                local actual = setfsuid(new_uid)
                if actual ~= new_uid then
                    ngx.log(ngx.CRIT, "Unable to impersonate users")
                    ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)
                end
            }
        }

        location = /auth {
            internal;
            proxy_pass              http://localhost:8080/auth;
            proxy_pass_request_body off;
            proxy_set_header        Content-Length "";
            proxy_set_header        X-Original-URI $request_uri;
            proxy_set_header        X-Original-Method $request_method;
        }
    }
}

Cela exécutera setfsuid sur chaque requête traitée par le travailleur nginx. Malheureusement, il semble que vous devez exécuter nginx en tant que root pour que cela fonctionne correctement actuellement. Je pense qu'il est possible que cela fonctionne avec un autre utilisateur à condition que le processus démarre en tant que root, déposé vers un autre utilisateur, avec CAP_SETUID conservé (voir la documentation pour capsh), et la userdirective est absente dans le fichier de configuration nginx.

Vous devrez peut-être également définir les ID de groupe, potentiellement.

Voir "Effet des changements d'ID utilisateur sur les capacités" dans http://man7.org/linux/man-pages/man7/capabilities.7.html


Cela semble prometteur. Je vérifierai.
Philip Couling

0

Cela peut valoir la peine d'être lu: Une autre entrée: plusieurs dossiers utilisateur et un dossier partagé http://hexeract.wordpress.com/2011/02/25/configure-a-webdav-enabled-webserver-for-multiple-user-folders -et-un-dossier-partagé /


Cela a le même problème que votre autre réponse. Certains utilisateurs ont un accès ssh. Les fichiers DOIVENT recevoir les droits et la propriété des fichiers Unix corrects (les leurs, et non ceux du serveur Web) (utilisateur et groupe).
Philip Couling du

0

J'ai utilisé celui-ci comme guide pour configurer webdav: http://bernaerts.dyndns.org/linux/75-debian/62-debian-webdav-share

oui, Apache est le groupe (www-data sous Debian) mais vous pouvez ajouter des utilisateurs à ce groupe, j'ai donc ajouté un utilisateur. N'a pas testé pourquoi vous ne pouvez pas ajouter d'autres utilisateurs .... Le serveur webdav utilisant en principe cette configuration fonctionne maintenant depuis 3 ans chez moi et chez mes fils (donc 2 serveurs identiques pour le travail de mon fils). Debian 6 est depuis quelques mois la version LTS (jusqu'en février 2016).

Par rapport à Bernaerts, j'ai adapté dans le fichier Apache: / etc / apache2 / sites-available / default cette partie de la configuration.

Alias /webdav1 /data/webdav1

<Location /webdav1>
DAV on
Authtype Basic
Authname "webdav1"
AuthUserFile /var/www/web1/passwd1.dav
Require valid-user
</location>

Donc, mes fichiers ne sont plus sous www mais dans / data / webdav1 (via l'alias webdav1 pour le garder court) Pour chaque disque dur j'ai créé une telle section et webdav1 devient webdav2 pour le 2ème disque dur de cette section. Nous pouvons construire au maximum 10 disques durs sur ces serveurs, donc 10 de ces sections dans ce fichier de configuration. J'ai ajouté l'utilisateur à www-data, davfs2 et davfs, afin que l'utilisateur puisse accéder au (x) dossier (s) webdav. L'utilisateur doit donc se connecter et il lui sera demandé le nom d'utilisateur et le mot de passe. Dans fstab, tous les disques de données webdav sont répertoriés afin que le montage se déroule automatiquement. Cette partie de fstab:

/ dev / sda3 / data / webdav1 ext3, utilisateur, auto 0 0


1
Malheureusement, cela ne résout pas du tout le problème. L'objectif de cette question était multi-utilisateurs. Avec cette solution, de nouveaux fichiers seront créés en tant qu'utilisateur apache et non en tant qu'utilisateur connecté. Afin de fonctionner apache, tous les fichiers doivent être un groupe www-data avec des autorisations de lecture / écriture sur ce groupe. Étant donné que chaque utilisateur devra être dans ce groupe, chaque utilisateur devra avoir accès à la lecture / écriture des fichiers de tous les autres utilisateurs. Cette solution ne fonctionne tout simplement pas pour plusieurs utilisateurs.
Philip Couling du

0

Avez-vous essayé OwnCloud ? Je ne fais que le tester moi-même, mais il semble que cela réponde à vos exigences: webdav fonctionne prêt à l'emploi.


1
Oui, j'ai une instance de Owncloud mais ce n'est pas ce que je recherche parce que l'utilisateur owncloud (apache) possède tous les fichiers.
Philip Couling

0

Après avoir cherché pendant longtemps, je n'en ai tout simplement pas trouvé. Il existe de nombreux serveurs multi-utilisateurs mais je n'ai pas pu en trouver un qui s'exécutait en tant qu'utilisateur système.

J'en ai donc écrit un moi-même. Ceci n'est testé que dans la mesure où je peux le tester moi-même. Mais pour ce que ça vaut, le code source est ici:

https://github.com/couling/WebDAV-Daemon


0

Hy,

Je cherchais la même chose et j'ai finalement trouvé une solution en utilisant apache2. J'ai essayé une solution de nœud en utilisant npm webdav-server et j'ai découvert que tout ne fonctionnait pas aussi bien qu'en utilisant le module apache. Ensuite, j'ai essayé un serveur npm dav basé sur jsDAV qui pourrait faire mieux et pourrait être une solution, mais comme je devais faire face à une mauvaise connexion 3g, j'ai préféré apache et découvert des scripts à instances multiples.

Alors là, je partage mon expérience.

http://helpcenter.epages.com/Doc/doc/apache2/README.multiple-instances

Je lance une instance par utilisateur webdav ... pas très évolutif, mais pour travailler en petite équipe c'est assez bien.

Remplacez myUser par votre utilisateur.

Sur Ubuntu 14.04

sh /usr/share/doc/apache2/examples/setup-instance myUser

Je lance donc un processus apache en tant qu'utilisateur myUser défini dans / etc / apache2-myUser / envars

export APACHE_RUN_USER=myUser
export APACHE_RUN_GROUP=myUser

Modifier ports.conf

# If you proxy with nginx as I did better to limit to local interface
listen localhost:8080
# listen 8080

Je ne pouvais pas faire fonctionner l'authentification PAM sur Ubuntu 14.04, je dois donc tromper avec l'authentification de base car je l'enveloppe ensuite dans https avec nginx

htpasswd -c /etc/apache2/htpasswd myUser

Ensuite /etc/apache2-myUser/sites-available/000-default.conf

<VirtualHost *:8080>

DocumentRoot /var/www/html

Alias /${APACHE_RUN_USER} /home/${APACHE_RUN_USER}
<Directory /home/${APACHE_RUN_USER}>
    Require all granted
    Options +Indexes
</Directory>

<Location /${APACHE_RUN_USER}>
      DAV On
      AuthType Basic
      AuthName "Restricted Area"
      AuthUserFile /etc/apache2/htpasswd
      Require valid-user
</Location>

DavLockDB /home/${APACHE_RUN_USER}/.DavLock
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

alors le proxy nginx a une astuce avec l'en-tête Le dossier des icônes de passage de destination permet à webdav de rétrograder bien sur les navigateurs

server {
listen 443 ssl http2;
server_name exemple.com;

location ~ ^/(myUser|icons)/ {

    proxy_pass http://dav-myUser;

#         auth_basic "Restricted Content";
#         auth_basic_user_file /etc/nginx/htpasswd;

#         proxy_set_header Authorization $http_authorization;

    proxy_pass_header  Authorization;
    proxy_pass_request_headers on;

    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;

    port_in_redirect off;

    # to avoid 502 Bad Gateway:
    # http://vanderwijk.info/Members/ivo/articles/ComplexSVNSetupFix
    set $destination $http_destination;

    if ($destination ~* ^https(.+)$) {
        set $destination http$1;
    }

    proxy_set_header Destination $destination;

    proxy_read_timeout     300;
    proxy_connect_timeout  5;

    # Default is HTTP/1, keepalive is only enabled in HTTP/1.1
    proxy_http_version 1.1;

    # Remove the Connection header if the client sends it,
    # it could be "close" to close a keepalive connection
    proxy_set_header Connection "";
}

ssl on;
ssl_certificate /etc/letsencrypt/live/exemple.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/exemple.com/privkey.pem;

include /etc/letsencrypt/options-ssl-nginx.conf;

}

Il n'y a aucune obligation d'utiliser nginx comme proxy, apache pourrait très bien faire le https, mais comme je suis tombé sur le problème de destination du proxy, j'ai senti qu'il valait la peine de le mentionner.


-1

Je recherche également une solution similaire.

Solution 1: votre environnement de bureau (Gnome, KDE) peut avoir des widgets pour exposer un certain dossier par WebDAV. Cela fonctionnera tant que votre environnement de bureau est en cours d'exécution et n'est pas une solution démon.

Solution 2: rien ne vous empêche d'exécuter Apache sous votre propre liaison utilisateur sur des ports non privilégiés supérieurs à 1024. Écrivez simplement un fichier de configuration ou copiez ceux fournis dans votre distribution dans votre $ HOME / etc / httpd (juste un exemple), ajoutez DAV- configuration associée et exécutez-le en tant que votre propre utilisateur non root comme:

$ httpd -f $ HOME / etc / httpd

L'exécution en tant que vos utilisateurs garantit qu'Apache créera des fichiers comme vous.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.