更新された問題の説明:

更新された問題の説明:

私の目標は、「チーム」グループのメンバーであるすべてのユーザーがローカルマウントポイントを使用して同じリモートファイルセットを編集(読み取り/書き込み)できるようにすることです。 ACLを使用してNFSとSSHFSを試しましたが、まだ成功していません。ここでは、umaskを正しく設定してSSHFSが機能するようにします(理論的には、これが私が経験している問題を解決する必要があります)。

更新された問題の説明:

user1、user2、およびuser3はすべて同じクライアントコンピュータにログインしています。誰もが「チーム」グループのメンバーです。クライアントコンピュータはSSHFSを介して共有をマウントします。クライアントとサーバーはArch Linuxを実行します(数日前に更新されました)。クライアントはKDEデスクトップを実行します。 SSHFSのマウントは、user3@sshfsrvとオプションallow_otherを使用して実行されます。

サーバー上の共有ディレクトリにはuser3(所有者)rwxおよびグループ(チーム)rwx権限があり、他のディレクトリにはrx権限があります。 gid固定ビットはで設定されますchmod g+s。 umask中心の設定のすべてのACLを削除しました。

最初の質問:

user2 は XSane (Gnome アプリケーション) を使用して文書をスキャンし、SSHFS マウントポイントの一部である Shared1 ディレクトリに保存しようとします。権限の問題のため、保管操作が失敗しました。 0バイトのファイルを書き込みます。このファイルの権限は、所有者(user3)rwとグループ(チーム)読み取り専用(他の権限なし)です。 user2はスキャンした文書を自分のホームディレクトリに保存できます。

端末は期待どおりに動作します。

ターミナルでは、user2は次の権限でShared1ディレクトリのドキュメントをタッチできます。

-rw-rw---- 1 user3 team 6 Sep 23 19:41 deleteme6.txt

正しい g+rw 権限を取得しました。所有権はuser3で、ファイルを作成した人はuser2でした。 /etc/fstab では、マウントは次のように指定されます。

user3@sshfsrv:/home/common /home/common fuse.sshfs x-systemd.automount,_netdev,user,follow_symlinks,identityfile=/home/user3/.ssh/id_rsa,allow_other,default_permissions               0 0

端末でテキストエディタ(KDEのKate)を使用すると、ユーザーはファイルを共同編集できます。Shared1で作成予想通り。チームグループのすべてのユーザーは、Nanoテキストエディタを介してShared1にファイルを作成して保存でき、グループの他のユーザーはファイルを編集/更新できます。

2番目の質問:

一時的な回避策としてスキャンした画像をuser2のホームディレクトリに保存し、Dolphinファイルマネージャを使用してShared1ディレクトリに移動する方法をテストしました。許可エラーが原因でこのようなことは発生せず、時にはドルフィンがクラッシュすることがあります。

端末でテキストファイルを移動して同じ結果を表示できます。

[user2@client2 Shared1]$ echo user2 > /home/user2/MoveMe/deleteme7.txt
[user2@client2 Shared1]$ mv /home/user2/MoveMe/deleteme7.txt .
mv: preserving times for './deleteme7.txt': Operation not permitted
mv: preserving permissions for ‘./deleteme7.txt’: Operation not permitted

上記の2つのエラーが問題を理解するための鍵であるようです。これらのエラーを使用するようにインストール仕様を変更すると、user2@sshfsrvこれらのエラーが消えて再び表示されuser2ます。問題のない唯一のユーザーは、インストール仕様で使用されているユーザーです。 (インストールオプションがこれを防ぐと思いましたが、そうではありません。インストール仕様で使用するのも役に立たないようです。)user1user3allow_otherroot

マウントオプションを削除すると、default_permissionsこれらのエラーは削除されますが、すべての権限の確認も削除されます。すべてのグループのすべてのユーザーが Shared1 のファイルを読み書きできますが、これは要件を満たしていません。

SFTPサーバーumask設定:

sebasth が以下に述べるように、sftp-server を使用する場合、/etc/profile または ~/.bashrc の umask は使用されません。 /etc/ssh/sshd_configでは、次の仕様がumask設定に最適なソリューションであることがわかりました。

Subsystem sftp internal-sftp -u 0006

sshfs(/ etc / fstabにあります)のumaskマウントオプションを使用したくありません。これは望ましい動作を提供しないからです。

残念ながら、上記の「-u」フラグは必須ですが、上記のように私の問題を(まだ)完全に解決することはできません。

新しいアップデート:

pam_umaskを有効にしましたが、これだけでは問題は解決しません。上記の「-u」オプションはまだ必要であり、pam_umaskがこの問題を解決するのに役立つ追加のエントリを追加するのを見ることはできません。現在使用されている構成は次のとおりです。

/etc/pam.d/system-login
session    optional   pam_umask.so

/etc/login.defs
UMASK           006

Shared1ディレクトリには、サーバー側に示すようにこれらの権限があります。 gid固定ビットはで設定されますchmod g+s。すべてのACLを削除しました。このディレクトリ内のすべてのファイルにはg + rw権限があります。

drwxrwsr-x  1 user3   team          7996 Sep 23 18:54 .

# cat /etc/group
team:x:50:user1,user2,user3

クライアントとサーバーの両方がOpenSSH_7.5p1、OpenSSL 1.1.0f(2017年5月25日)を実行しています。これが最新バージョンのようです。

サーバーにはsystemctl status sshdマスターPID:4853(sshd)が表示されます。デフォルトのプロセス状態は、umask が 022 と表示されます。しかし、正しいumask 006を示すsftpサブシステムのプロセス情報を以下に提供します。

# cat /proc/4853/status
Name:   sshd
Umask:  0022
State:  S (sleeping)
Tgid:   4853
Ngid:   0
Pid:    4853
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 64
Groups:  
NStgid: 4853
NSpid:  4853
NSpgid: 4853
NSsid:  4853
VmPeak:    47028 kB
VmSize:    47028 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:      5644 kB
VmRSS:      5644 kB
RssAnon:             692 kB
RssFile:            4952 kB
RssShmem:              0 kB
VmData:      752 kB
VmStk:       132 kB
VmExe:       744 kB
VmLib:      6260 kB
VmPTE:       120 kB
VmPMD:        16 kB
VmSwap:        0 kB
HugetlbPages:          0 kB
Threads:        1
SigQ:   0/62965
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000180014005
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
Seccomp:        0
Cpus_allowed:   3f
Cpus_allowed_list:      0-5
Mems_allowed:   00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        25
nonvoluntary_ctxt_switches:     2

このクライアントのSFTPサーバープロセスを確認する必要があります。予想されるumask 006が表示されます。 GIDが正しいかどうかはわかりません。 1002はuser3グループのGIDです。このディレクトリはチームグループ(GID 50)rwxを指定します。

# ps ax | grep sftp*
5112 ?        Ss     0:00 sshd: user3@internal-sftp


# cat /proc/5112/status
Name:   sshd
Umask:  0006
State:  S (sleeping)
Tgid:   5112
Ngid:   0
Pid:    5112
PPid:   5111
TracerPid:      0
Uid:    1002    1002    1002    1002
Gid:    1002    1002    1002    1002
FDSize: 64
Groups: 47 48 49 50 51 52 1002 
NStgid: 5112
NSpid:  5112
NSpgid: 5112
NSsid:  5112
VmPeak:    85280 kB
VmSize:    85276 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:      3640 kB
VmRSS:      3640 kB
RssAnon:             980 kB
RssFile:            2660 kB
RssShmem:              0 kB
VmData:     1008 kB
VmStk:       132 kB
VmExe:       744 kB
VmLib:      7352 kB
VmPTE:       184 kB
VmPMD:        12 kB
VmSwap:        0 kB
HugetlbPages:          0 kB
Threads:        1
SigQ:   0/62965
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180010000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
Seccomp:        0
Cpus_allowed:   3f
Cpus_allowed_list:      0-5
Mems_allowed:   00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        8
nonvoluntary_ctxt_switches:     0

元の質問 - 上記の更新後はスキップできます。

SSHFSファイルサーバーのShared1ディレクトリをさまざまなクライアントコンピュータに共有しています。すべてのマシンはArch LinuxとBTRFSを使用します。pwckそして、grpckクライアントとサーバーの両方でエラーは報告されません。

私の目標は、チームグループのすべてのユーザーがShared1ディレクトリに対するrw権限を持つようにすることです。未知の理由でこの目標を達成することはできません。一部のグループメンバーは、以下のように権限拒否エラー(作成中)が発生しました。

私は何を見落としていますか? (unix.stackexchange.comですべての関連質問を確認しましたが、まだこの問題を解決できませんでした。)

仕える人:

[user2@sshfsrv Shared1]$ cat /etc/profile
umask 006

[user2@sshfsrv Syncd]$ whoami
user2

[user2@sshfsrv Syncd]$ groups
team user2

[user2@sshfsrv Syncd]$ cat /etc/fuse.conf 
user_allow_other

[root2@sshfsrv Syncd]# cat /proc/18940/status
Name:   sshd
Umask:  0022

以下の setgid bit() はchmod g+s最初に設定されています。

[user1@sshfsrv Syncd]$ ls -la
total 0
drwxrws--x 1 user1 limited     170 Aug 29 09:47 .
drwxrwxr-x 1 user1 limited      10 Jul  9 14:10 ..
drwxrwsr-x 1 user2 team       7892 Sep 22 17:21 Shared1

[root@sshfsrv Syncd]# getfacl Shared1/
# file: Shared1/
# owner: user2
# group: team
# flags: -s-
user::rwx
group::rwx
other::r-x

[user2@sshfsrv Shared1]$ umask -S
u=rwx,g=rx,o=x

[user2@sshfsrv Shared1]$ sudo chmod g+w .

[user2@sshfsrv Shared1]$ umask -S
u=rwx,g=rx,o=x

注:上記の手順を完了しても、グループへの書き込み権限はありません。

[user2@sshfsrv Shared1]$ touch deleteme2.txt
[user2@sshfsrv Shared1]$ echo deleteme > deleteme2.txt 
[user2@sshfsrv Shared1]$ cat deleteme2.txt 
deleteme
[user2@sshfsrv Shared1]$ ls -la deleteme2.txt 
-rw-r----- 1 user2 team 9 Sep 22 17:55 deleteme2.txt

[user2@sshfsrv Shared1]$ getfacl .
# file: .
# owner: user2
# group: team
# flags: -s-
user::rwx
group::rwx
other::r-x

[root@sshfsrv Syncd]# chmod g-s Shared1/
[root@sshfsrv Syncd]# ls -la
drwxrwxr-x 1 user2      team         7944 Sep 22 17:54 Shared1

顧客

[user2@client2 Shared1]$ cat /etc/fstab
user3@sshfsrv:/home/common /home/common fuse.sshfs x-systemd.automount,_netdev,user,follow_symlinks,identityfile=/home/user3/.ssh/id_rsa,allow_other,default_permissions               0 0

[user2@client2 Shared1]$ cat /etc/profile
umask 006

[user2@client2 Shared1]$ cat /etc/fuse.conf 
user_allow_other

[user2@client2 Shared1]$ groups
team user2

[user2@client2 Shared1]$ echo deleteme > deleteme2.txt
bash: deleteme2.txt: Permission denied

[user2@client2 Shared1]$ touch deleteme3.txt
touch: setting times of 'deleteme3.txt': Permission denied

[user2@client2 Shared1]$ ls -la
total 19520
drwxrwsr-x 1 user2 team       7918 Sep 22 17:51 .
drwxrws--x 1 user1 limited     170 Aug 29 09:47 ..
-rw-r----- 1 user3 team          0 Sep 22 17:51 deleteme3.txt

答え1

一般的な解決策は、Arch Linuxの/etc/ssh/sshd_configに次の行を追加することです。

Subsystem sftp internal-sftp -u 0002

しかし、私にとって問題は、「チーム」グループのユーザーが同じプロファイルにForceCommandを定義したことです。これらのユーザーの場合、ForceCommand は上記の仕様以上を提供します。

解決策は、ForceCommandに同じ「-u」フラグを追加することです。

Match Group team
   ForceCommand internal-sftp -u 0002 

次に、次を実行します。

systemctl restart sshd.service

sshfsマウントオプションumaskを使用することはお勧めできません。私が望む動作は出ません。

引用:

sshfsのumaskオプションは、デフォルトのメルトダウン層の奥深くに入り、誤って処理されます。私のアドバイスはそれを避けることです。 – Ralph Rehnquist 2016年6月17日午後7時56分sshfsとumaskについて学ぶ

編集する:

このソリューションは、コマンドラインや一部のデスクトップアプリケーション(KDEのKateテキストエディタなど)では機能しますが、多くのデスクトップアプリケーション(KDEのDolphinファイルマネージャ、XSAneなどを含む)ではうまく機能しません。したがって、これは全体的に良い解決策ではありません。

答え2

いつSFTPサーバー使用すると、マスクでは/etc/profile使用されません。設定できますマスクモジュールを持つすべてのユーザーセッション(シェルを含む)の場合pam_umask。に接続する/etc/pam.d/system-login

session    optional   pam_umask.so

umask値を設定します/etc/login.defs

答え3

私が見た回答には以下が含まれていないので、CHROOTED sftpを試みる管理者のためにこれを追加します。

構成で「ForceCommand inside-sftp -u 0027」または必要なumaskを別々に指定する必要があります。つまり..

  Match Group sftp_users
   ChrootDirectory /var/www/
   ForceCommand internal-sftp -u 0027
   X11Forwarding no
   AllowTcpForwarding no
   PasswordAuthentication yes

これは競合グループとは完全に独立しています。答えを見つけることに夢中になるので、これを追加することです。

関連情報