Esiste un server webdav multiutente disponibile per Linux?


9

Sto cercando di rimuovere completamente il servizio SMBA e sostituirlo con un servizio WebDav.

Tutte le ricerche su Google finora mi hanno indicato di usare Apache / Webdav. Questo è vicino a ciò di cui ho bisogno, ma per quanto leggo richiede che Apache abbia accesso ai file del mio utente e peggio; se crea un file, il nuovo file sarà di proprietà di Apache (non dell'utente). Si noti che disporre di file con la proprietà e le autorizzazioni Unix corrette è un requisito in quanto alcuni utenti dispongono dell'accesso SSH diretto.

Quindi sto semplicemente cercando un modo per far funzionare Apache / Webdav "correttamente" con più utenti (ovvero cambiare l'utente unix prima dell'utente tentato di servire il file ) o trovare un'alternativa completa ad Apache / WebDAV.

Finora le ricerche non hanno rivelato nulla.


Poiché webdav si basa sul protocollo HTTP, direi che non esiste se non sotto forma di un server HTTP. E se trovi un prodotto che offre webdav, Trhey di solito offrirà di più
Kiwy,

Sembra che ci possa essere qualcosa di promettente nell'ultima versione di MPM ITK. mpm-itk.sesse.net Proverò con questo e vedrò se AssignUserIDExpraccetterò l'utente che ha effettuato l'accesso. Da allora potrebbe non AssignUserIDapparire prima che l'utente esegua l'autenticazione.
Philip Couling,

Esistono server webdav autonomi come code.google.com/p/opendav o librerie come PyWebDAV che non richiedono apache.
Jan

@jan Potrebbe essere la risposta migliore. Apache è già in esecuzione sul server e webdav dovrebbe essere una sottodirectory del sito, ma posso impostarlo come proxy pass-through e utilizzare SSL di Apache per fornire la crittografia.
Philip Couling,

1
Dovrebbe essere spostato in Software Raccomandations.SE .
William Edwards,

Risposte:


2

Se hai il nome utente e / o l'UID, puoi farlo con nginx + lua + luarocks ljsyscall

Su un sistema debian, configurato come:

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

E nginx è configurato nel modo seguente:

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;
        }
    }
}

Questo eseguirà setfsuid su ogni richiesta gestita dal lavoratore nginx. Sfortunatamente, sembra che tu stia eseguendo nginx come root per farlo funzionare correttamente. Credo che sia possibile lavorare con un altro utente a condizione che il processo sia iniziato come root, passato a un altro utente, con CAP_SETUID conservato (consultare la documentazione per capsh) e la userdirettiva è assente nel file di configurazione di nginx.

Potrebbe anche essere necessario impostare gli ID di gruppo, potenzialmente.

Vedi "Effetto delle modifiche dell'ID utente sulle capacità" in http://man7.org/linux/man-pages/man7/capabilities.7.html


Sembra promettente. Lo guarderò.
Philip Couling,


0

Ho usato questo come guida per configurare webdav: http://bernaerts.dyndns.org/linux/75-debian/62-debian-webdav-share

sì, Apache è il gruppo (dati www in Debian) ma è possibile aggiungere utenti a quel gruppo, quindi ho aggiunto un utente. Non ho testato il motivo per cui non è possibile aggiungere altri utenti .... Il server webdav utilizza in linea di principio questa configurazione ora funziona per 3 anni a casa mia e di mio figlio (quindi 2 server identici per il lavoro di mio figlio). Debian 6 è da alcuni mesi la versione LTS (fino a febbraio 2016).

Rispetto a Bernaerts ho adattato nel file Apache: / etc / apache2 / sites-available / default questa parte della configurazione.

Alias /webdav1 /data/webdav1

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

Quindi i miei file non sono più in www ma in / data / webdav1 (tramite alias webdav1 per farla breve) Per ogni disco rigido che ho creato una tale sezione e webdav1 diventa webdav2 per il 2 ° disco rigido in quella sezione. In questi server è possibile creare un massimo di 10 dischi rigidi, quindi 10 di queste sezioni in quel file di configurazione. Ho aggiunto l'utente a www-data, davfs2 e davfs, in modo che l'utente possa accedere alle cartelle webdav. Quindi l'utente deve effettuare il login e verrà richiesto il nome utente e la password. In fstab sono elencati tutti i dischi di dati webdav in modo che il montaggio proceda automaticamente. Quella parte di fstab:

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


1
Purtroppo questo non risolve affatto il problema. Il focus di questa domanda era multiutente. Con questa soluzione verranno creati nuovi file come utente apache e non come utente connesso. Per funzionare con apache tutti i file devono essere un gruppo www-data con autorizzazioni di lettura / scrittura per quel gruppo. Poiché ogni utente dovrà appartenere a quel gruppo, ogni utente dovrà avere accesso alla lettura / scrittura dei file di ogni altro utente. Questa soluzione semplicemente non si attiva per più utenti.
Philip Couling,

0

Hai provato OwnCloud ? Lo sto ancora testando da solo, ma sembra che soddisfi le tue esigenze: webdav è pronto all'uso.


1
Sì, ho un'istanza di Owncloud ma non è quello che sto cercando perché l'utente owncloud (apache) possiede tutti i file.
Philip Couling,

0

Avendo cercato a lungo non riuscivo a trovarne uno. Esistono molti server multiutente, ma non sono riuscito a trovarne uno eseguito come utente di sistema.

Quindi ne ho scritto uno io. Questo è testato solo per quanto posso provarlo da solo. Ma per quello che vale, il codice sorgente è qui:

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


0

Hy,

Stavo cercando la stessa cosa e finalmente ho raccolto una soluzione usando apache2. Ho provato la soluzione di nodo usando npm webdav-server e ho scoperto che non tutti hanno funzionato altrettanto bene usando il modulo apache. Quindi ho provato un npm dav-server basato su jsDAV che poteva fare di meglio e poteva essere una soluzione, ma dato che dovevo affrontare una pessima connessione 3G ho preferito apache e ho scoperto degli script a più istanze.

Quindi qui condivido la mia esperienza.

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

Corro un'istanza per utente webdav ... non molto scalabile, ma per lavorare in un piccolo team è abbastanza buono.

Sostituisci myUser con il tuo utente.

Su Ubuntu 14.04

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

Quindi eseguo un processo apache come definito dall'utente myUser in / etc / apache2-myUser / envars

export APACHE_RUN_USER=myUser
export APACHE_RUN_GROUP=myUser

Modifica ports.conf

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

Non sono riuscito a far funzionare PAM auth su Ubuntu 14.04, quindi ho bisogno di ingannare con l'autent di base mentre lo avvolgo in https con nginx

htpasswd -c /etc/apache2/htpasswd myUser

Quindi /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>

quindi il proxy nginx ha un trucco con l'intestazione La cartella delle icone di passaggio di destinazione consente di eseguire il downgrade di webdav sui browser

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;

}

Non vi è alcun obbligo di utilizzare nginx come proxy, Apache potrebbe benissimo fare l'https, ma dato che mi sono imbattuto nel problema con la destinazione proxy ho sentito che valeva la pena menzionarlo.


-1

Sto anche cercando una soluzione simile.

Soluzione 1: l'ambiente desktop (Gnome, KDE) potrebbe disporre di widget per esporre una determinata cartella tramite WebDAV. Questo funzionerà finché l'ambiente desktop è in esecuzione e non è una soluzione demone.

Soluzione 2: nulla impedisce di eseguire Apache con il proprio binding utente su porte non privilegiate superiori a 1024. Basta scrivere un file di configurazione o copiare quelli raggruppati nella distribuzione su $ HOME / etc / httpd (solo un esempio), aggiungere DAV- configurazione correlata ed eseguirlo come proprio utente non root come:

$ httpd -f $ HOME / etc / httpd

Funzionando come i tuoi utenti si assicura che Apache creerà i file come te.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.