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を実行している必要があります。 rootとして開始され、CAP_SETUIDが保持された状態で別のユーザーにドロップされたプロセス（capshのドキュメントを参照）を提供し、userディレクティブがnginx設定ファイルにはありません。
場合によっては、グループIDの設定が必要になることもあります。
http://man7.org/linux/man-pages/man7/capabilities.7.html の「機能に対するユーザーIDの変更の影響」を参照してください
OwnCloud を試しましたか？まだ自分でテストしているだけですが、要件を満たしているようです。webdavはそのまま使用できます。
これをガイドとして使用して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を介して）。各ハードディスクに対してそのようなセクションを作成し、そのセクションの2番目のハードディスクのwebdav1がwebdav2になります。これらのサーバーには最大10台のハードディスクを組み込むことができるので、その構成ファイルのこれらのセクションの10個です。ユーザーをwww-data、davfs2、davfsに追加して、ユーザーがwebdavフォルダーにアクセスできるようにしました。したがって、ユーザーはログインする必要があり、ユーザー名とパスワードの入力を求められます。 fstabにすべてのwebdavデータディスクが一覧表示され、マウントが自動的に続行されます。 fstabのその部分：
/ dev/sda3/data/webdav1 ext3、user、auto 0 0
これは読む価値があるかもしれません：別の入力：複数のユーザーフォルダーと1つの共有フォルダー http://hexeract.wordpress.com/2011/02/25/configure-a-webdav-enabled-webserver-for-multiple -user-folders-and-one-shared-folder /
やあ、
私は同じものを探していて、ついに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プロキシにはヘッダーDestination Passing Iconsフォルダがあるトリックがあり、ブラウザで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をうまく実行できますが、プロキシの宛先の問題にぶつかったので、言及する価値があると感じました。