Linuxで使用できるマルチユーザーwebdavサーバーはありますか？

私のSMBAサービスを完全に廃止し、WebDavサービスに置き換えたいと考えています。

これまでのすべてのGoogle検索で、Apache / Webdavを使用するように指示されてきました。これは私が必要とするものに近いですが、私が読む限りでは、Apacheがユーザーのファイルにアクセスする必要があり、さらに悪いことです。ファイルを作成する場合、新しいファイルは（ユーザーではなく）Apacheが所有します。 一部のユーザーはSSHに直接アクセスできるため、正しいUnixの所有権と権限を持つファイルを用意することが必要です。

だから私は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;
        }
    }
}

これにより、nginxワーカーによって処理されるすべてのリクエストでsetfsuidが実行されます。残念ながら、これが現在正しく機能するためには、rootとしてnginxを実行している必要があります。私はそれが別のユーザーで動作するように、このことは可能だが、ルートとして起動されたプロセスを提供CAP_SETUIDケーパビリティは（のためのマニュアルを参照して保存し、別のユーザーに低下したと考えているcapsh）、およびuserディレクティブは、nginxの設定ファイルに存在しません。

場合によっては、グループIDの設定が必要になることもあります。

http://man7.org/linux/man-pages/man7/capabilities.7.htmlの「機能に対するユーザーIDの変更の影響」を参照して ください

これは読む価値があるかもしれません：別の入力：複数のユーザーフォルダーと1つの共有フォルダー http://hexeract.wordpress.com/2011/02/25/configure-a-webdav-enabled-webserver-for-multiple-user-folders -and-one-shared-folder /

これをガイドとして使用して、webdavをセットアップしました：http ://bernaerts.dyndns.org/linux/75-debian/62-debian-webdav-share

はい、Apacheはグループ（Debianではwww-data）ですが、そのグループにユーザーを追加できるため、1人のユーザーを追加しました。他のユーザーを追加できない理由をテストしませんでした...原則としてこの設定を使用するwebdavサーバーは、息子と息子の場所で3年間稼働するようになりました（息子の仕事用に2つの同一サーバー）。Debian 6は数か月前からLTSバージョンです（2016年2月まで）。

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はそのセクションの2番目のハードディスクのwebdav2になります。これらのサーバーには最大10台のハードディスクを組み込むことができるので、その構成ファイルのこれらのセクションの10個です。ユーザーをwww-data、davfs2、davfsに追加して、ユーザーがwebdavフォルダーにアクセスできるようにしました。したがって、ユーザーはログインする必要があり、ユーザー名とパスワードの入力を求められます。fstabにすべてのwebdavデータディスクが一覧表示され、マウントが自動的に続行されます。fstabのその部分：

/ dev / sda3 / data / webdav1 ext3、user、auto 0 0

OwnCloudを試しましたか？まだ自分でテストしているだけですが、要件を満たしているようです。webdavはそのまま使用できます。

長い間探していたのに見つからなかった。マルチユーザーサーバーは多数ありますが、システムユーザーとして実行されるサーバーは見つかりませんでした。

だから私は自分で書いた。これは私が自分でテストできる範囲でのみテストされています。しかし、その価値のために、ソースコードはここにあります：

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

やあ、

私は同じものを探していて、ようやくapache2を使用してソリューションを収集しました。npm webdav-serverを使用してノードソリューションを試したところ、すべてがapacheモジュールを使用した場合ほどうまく機能していないことがわかりました。次に、jsDAVをベースにしたnpm dav-serverを試してみましたが、パフォーマンスが向上し、解決策になる可能性があります。

だからここに私の経験を共有します。

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

私はwebdavユーザーごとにインスタンスを実行しています...あまりスケーラブルではありませんが、小さなチームで作業するには十分です。

myUserを自分のユーザーに置き換えます。

Ubuntu 14.04の場合

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

したがって、/ etc / apache2-myUser / envarsで定義されたユーザーmyUserとしてApacheプロセスを実行します

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

私はubuntu 14.04でPAM認証を機能させることができなかったので、それをnginxでhttpsにラップするので、基本認証でトリックする必要があります

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：1024を超える非特権ポートで独自のユーザーバインディングの下で​​Apacheを実行することを妨げるものは何もありません。構成ファイルを作成するか、ディストリビューションにバンドルされているものを$ HOME / etc / httpd（単なる例）にコピーし、DAV-を追加します。関連する設定とあなた自身の非ルートユーザーとしてそれを実行します：

$ httpd -f $ HOME / etc / httpd

ユーザーとして実行すると、Apacheがあなたと同じようにファイルを作成します。