Существует ли многопользовательский сервер webdav для Linux?

Я ищу, чтобы полностью вывести мой сервис SMBA и заменить его сервисом WebDav.

Все поиски в Google до сих пор указывали мне на использование Apache / Webdav. Это близко к тому, что мне нужно, но, поскольку я читаю, требуется, чтобы у Apache был доступ к файлам моего пользователя и хуже; если он создает файл, новый файл будет принадлежать Apache (а не пользователю). Обратите внимание, что наличие файлов с правильными владельцами и разрешениями Unix является обязательным, поскольку некоторые пользователи имеют прямой доступ по SSH.

Поэтому я довольно просто ищу способ заставить Apache / Webdav «правильно» работать с несколькими пользователями (то есть сменить пользователя unix на пользователя, вошедшего в систему, прежде чем пытаться обслуживать файл ) или найти полную альтернативу Apache / Webdav.

Пока что поиски ничего не нашли.

Если у вас есть имя пользователя и / или uid, вы можете сделать это с помощью nginx + lua + luarocks ljsyscall

В системе Debian, настроенной как:

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

И nginx настроил так:

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

Это будет выполнять setfsuid для каждого запроса, обслуживаемого работником nginx. К сожалению, похоже, что вы должны запустить nginx от имени root, чтобы это работало прямо сейчас. Я полагаю, что это возможно для работы с другим пользователем, при условии, что процесс запущен от имени пользователя root, прерван для другого пользователя с сохраненным CAP_SETUID (см. Документацию capsh), а userдиректива отсутствует в файле конфигурации nginx.

Возможно, вам также может понадобиться установить идентификаторы группы.

См. «Влияние изменений идентификатора пользователя на возможности» в http://man7.org/linux/man-pages/man7/capabilities.7.html.

Это может стоить прочитать: Другой вход: несколько пользовательских папок и одна общая папка http://hexeract.wordpress.com/2011/02/25/configure-a-webdav-enabled-webserver-for-multiple-user-folders и-один-разделяемой папке /

Я использовал это в качестве руководства для настройки webdav: http://bernaerts.dyndns.org/linux/75-debian/62-debian-webdav-share

да, Apache - это группа (www-data под Debian), но вы можете добавить пользователей в эту группу, поэтому я добавил одного пользователя. Не проверял, почему вы не можете добавлять других пользователей .... Сервер webdav, использующий в принципе эту настройку, теперь работает в течение 3 лет у меня и у моих сыновей (так что 2 идентичных сервера для работы моего сына). Debian 6 уже несколько месяцев является версией LTS (до февраля 2016 года).

По сравнению с Bernaerts я адаптировал в файле Apache: / etc / apache2 / sites-available / default эту часть конфигурации.

Alias /webdav1 /data/webdav1

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

Таким образом, мои файлы больше не находятся под www, а находятся в / data / webdav1 (через псевдоним webdav1 для краткости). Для каждого жесткого диска, который я создал, такой раздел и webdav1 становится webdav2 для второго жесткого диска в этом разделе. Мы можем встроить до 10 жестких дисков на этих серверах, так что 10 из этих разделов в этом файле конфигурации. Я добавил пользователя в www-data, davfs2 и davfs, чтобы пользователь мог получить доступ к папкам (папкам) webdav. Таким образом, пользователь должен войти в систему и будет предложено ввести имя пользователя и пароль. В fstab перечислены все диски с данными webdav, поэтому монтирование происходит автоматически. Эта часть fstab:

/ dev / sda3 / data / webdav1 ext3, пользователь, авто 0 0

Вы пробовали OwnCloud ? Все еще просто тестирую сам, но похоже, что он отвечает вашим требованиям: webdav работает "из коробки".

Долго искав, я просто не смог найти. Есть много многопользовательских серверов, но я не смог найти тот, который выполнялся как системный пользователь.

Так что я написал один сам. Это только проверено, насколько я могу проверить это сам. Но для чего он стоит, исходный код здесь:

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

Hy,

Я искал то же самое, и я наконец-то собрал решение, используя apache2. Я попробовал решение узлов с помощью npm webdav-server и обнаружил, что не все работает так же хорошо, как при использовании модуля apache. Затем я попробовал dav-сервер npm, основанный на jsDAV, который мог бы работать лучше и мог бы стать решением, но, поскольку мне приходилось иметь дело с паршивым соединением 3g, я предпочел apache и узнал о сценариях с несколькими экземплярами.

Вот и я делюсь своим опытом.

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

Я запускаю экземпляр для каждого пользователя webdav ... не очень масштабируемый, но для работы в небольшой команде это достаточно хорошо.

Замените myUser вашим пользователем.

На Ubuntu 14.04

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

Поэтому я запускаю процесс apache как пользователь myUser, определенный в / etc / apache2-myUser / envars

export APACHE_RUN_USER=myUser
export APACHE_RUN_GROUP=myUser

Редактировать ports.conf

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

Я не смог заставить работать PAM-аутентификацию на Ubuntu 14.04, поэтому мне нужно работать с базовой аутентификацией, так как я затем обертываю его в https с помощью nginx

htpasswd -c /etc/apache2/htpasswd myUser

Затем /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>

тогда у прокси nginx есть хитрость с заголовком. Папка с иконками прохождения назначения позволяет webdav понизить версию в браузерах

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;

}

Нет необходимости использовать nginx в качестве прокси-сервера, apache вполне может выполнить https, но, столкнувшись с проблемой назначения прокси, я почувствовал, что стоит упомянуть об этом.

Я также ищу подобное решение.

Решение 1. В вашей среде рабочего стола (Gnome, KDE) могут быть виджеты, которые открывают определенную папку с помощью WebDAV. Это будет работать до тех пор, пока ваша рабочая среда работает и не является решением демона.

Решение 2. Ничто не мешает вам запускать Apache под собственной привязкой пользователя на непривилегированных портах выше 1024. Просто напишите файл конфигурации или скопируйте файлы, включенные в ваш дистрибутив, в ваш $ HOME / etc / httpd (просто пример), добавьте DAV- связанный конфиг и запустите его от имени своего пользователя без полномочий root, например:

$ httpd -f $ HOME / etc / httpd

Запуск от имени ваших пользователей гарантирует, что Apache будет создавать файлы как вы.