¿Hay un servidor webdav multiusuario disponible para Linux?

Estoy buscando retirar completamente mi servicio SMBA y reemplazarlo con un servicio WebDav.

Todas las búsquedas de Google hasta el momento me han indicado utilizar Apache / Webdav. Esto está cerca de lo que necesito, pero por lo que leo, requiere que Apache tenga acceso a los archivos de mi usuario y peor; si crea un archivo, el nuevo archivo será propiedad de Apache (no del usuario). Tenga en cuenta que tener archivos con la propiedad y permisos Unix correctos es un requisito, ya que algunos usuarios tienen acceso SSH directo.

Así que simplemente estoy buscando una manera de hacer que Apache / Webdav funcione "correctamente" con múltiples usuarios (es decir, cambiar el usuario de Unix al usuario conectado antes de intentar servir el archivo ) o encontrar una alternativa completa a Apache / Webdav.

Hasta ahora, las búsquedas no han dado resultado.

Si tiene el nombre de usuario y / o el UID, puede hacerlo con nginx + lua + luarocks ljsyscall

En un sistema debian, configurado como:

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

Y nginx configuró de la siguiente manera:

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

Esto ejecutará setfsuid en cada solicitud atendida por el trabajador nginx. Desafortunadamente, parece que debe estar ejecutando nginx como root para que esto funcione actualmente. Creo que es posible que esto funcione con un usuario diferente siempre que el proceso se inicie como root, se deje caer a un usuario diferente, con CAP_SETUID preservado (consulte la documentación para capsh), y la userdirectiva está ausente en el archivo de configuración nginx.

Es posible que también deba establecer las ID de grupo, potencialmente.

Consulte "Efecto de los cambios de ID de usuario en las capacidades" en http://man7.org/linux/man-pages/man7/capabilities.7.html

Vale la pena leer esto: Otra entrada: múltiples carpetas de usuario y una carpeta compartida http://hexeract.wordpress.com/2011/02/25/configure-a-webdav-enabled-webserver-for-multiple-user-folders -and-one-shared-folder /

Usé este como guía para configurar webdav: http://bernaerts.dyndns.org/linux/75-debian/62-debian-webdav-share

sí, Apache es el grupo (www-data en Debian) pero puede agregar usuarios a ese grupo, así que agregué un usuario. No probé por qué no puede agregar otros usuarios ... El servidor webdav que utiliza, en principio, esta configuración se ejecuta ahora durante 3 años en mi y mis hijos (2 servidores idénticos para el trabajo de mi hijo). Debian 6 es desde hace algunos meses la versión LTS (hasta febrero de 2016).

En comparación con Bernaerts, adapté en el archivo Apache: / etc / apache2 / sites-available / default esta parte de la configuración.

Alias /webdav1 /data/webdav1

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

Por lo tanto, mis archivos ya no están en www sino en / data / webdav1 (a través de alias webdav1 para mantenerlo corto) Para cada disco duro, he creado una sección de este tipo y webdav1 se convierte en webdav2 para el segundo disco duro de esa sección. Podemos construir un máximo de 10 discos duros en estos servidores, por lo que 10 de estas secciones en ese archivo de configuración. Agregué el usuario a www-data, davfs2 y davfs, para que el usuario pueda tener acceso a las carpetas webdav. Por lo tanto, el usuario debe iniciar sesión y se le pedirá el nombre de usuario y la contraseña. En fstab, todos los discos de datos webdav se enumeran para que el montaje se realice automáticamente. Esa parte de fstab:

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

¿Has probado OwnCloud ? Todavía lo pruebo yo mismo, pero parece que cumple con sus requisitos: webdav funciona de forma inmediata.

Después de haber buscado durante mucho tiempo, no pude encontrar uno. Hay muchos servidores multiusuario, pero no pude encontrar uno que se ejecutara como usuario del sistema.

Entonces escribí uno yo mismo. Esto solo se prueba hasta donde puedo probarlo yo mismo. Pero por lo que vale, el código fuente está aquí:

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

Hy

Estaba buscando lo mismo y finalmente reuní una solución usando apache2. Intenté la solución de nodo con npm webdav-server y descubrí que no todo funcionaba tan bien que con el módulo apache. Luego probé un servidor npm dav basado en jsDAV que podría funcionar mejor y podría ser una solución, pero como tuve que lidiar con una pésima conexión 3g, preferí apache y descubrí scripts de varias instancias.

Así que aquí comparto mi experiencia.

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

Ejecuto una instancia por usuario de webdav ... no muy escalable, pero trabajar en un equipo pequeño es lo suficientemente bueno.

Reemplace myUser con su usuario.

En Ubuntu 14.04

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

Entonces ejecuto un proceso de Apache como el usuario myUser definido en / etc / apache2-myUser / envars

export APACHE_RUN_USER=myUser
export APACHE_RUN_GROUP=myUser

Editar puertos.conf

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

No pude hacer que la autenticación PAM en ubuntu 14.04 funcione, así que necesito engañar con la autenticación básica, ya que luego la envuelvo en https con nginx

htpasswd -c /etc/apache2/htpasswd myUser

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

entonces el proxy nginx tiene un truco con el encabezado La carpeta de iconos de paso de destino permite que webdav baje de categoría agradablemente en los navegadores

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;

}

No hay obligación de usar nginx como proxy, apache bien podría hacer https, pero cuando me topé con el problema de Destino de proxy, sentí que valía la pena mencionarlo.

También estoy buscando una solución similar.

Solución 1: Su entorno de escritorio (Gnome, KDE) podría tener widgets para exponer una determinada carpeta por WebDAV. Esto se ejecutará mientras se ejecute su entorno de escritorio y no sea una solución daemon.

Solución 2: Nada le impide ejecutar Apache bajo su propio enlace de usuario en puertos no privilegiados superiores a 1024. Simplemente escriba un archivo de configuración o copie los que se incluyen en su distribución a su $ HOME / etc / httpd (solo un ejemplo), agregue DAV- configuración relacionada y ejecútela como su propio usuario no root como:

$ httpd -f $ INICIO / etc / httpd

La ejecución de sus usuarios garantiza que Apache creará archivos como usted.