SFTPトランザクションのumaskを設定する適切な方法は？
私の目標は、「チーム」グループのメンバーであるすべてのユーザーが、ローカルマウントポイントを使用して、リモートファイルの同じセット（通常の作業コラボレーション）を編集（r/w）できるようにすることです。 ACLを使用してNFSとSSHFSを試しましたが、まだ成功していません。ここでは、umaskを正しくすることで、SSHFSを機能させようとしています（理論的には、発生している問題を解決するはずです）。
問題の更新された説明：
user1、user2、およびuser3はすべて同じクライアントコンピュータにログインします。全員がグループ「チーム」のメンバーです。クライアントコンピューターは、SSHFSを介して共有をマウントします。クライアントとサーバーはArch Linuxを実行します（数日前に更新されました）。クライアントはKDEデスクトップを実行します。 SSHFSマウントは、user3 @ sshfsrvとオプションallow_otherを使用して行われます。
サーバー上では、共有ディレクトリにはuser3（所有者）rwxおよびグループ（チーム）rwxの権限があり、他のユーザーにはr-x権限があります。 gidスティッキビットはchmod g+sで設定されます。 umaskに焦点を当てた構成のすべてのACLを削除しました。
最初の問題：
user2はXSane（Gnomeアプリ）でドキュメントをスキャンし、SSHFSマウントポイントの一部であるShared1ディレクトリに保存しようとします。権限が原因で保存操作が失敗します。 0バイトのファイルが書き込まれます。そのファイルの権限は、所有者（user3）のrwとグループ（team）の読み取り専用（およびその他の権限）です。 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で作成されたもの期待どおり。グループ「team」のユーザーは、nanoテキストエディターを介してShared1にファイルを作成および保存できます。グループの他のユーザーは、ファイルを編集/更新できます。
2番目の問題：
一時的な回避策として、スキャンしたイメージをuser2のホームディレクトリに保存し、Dolphinファイルマネージャを使用してそれらをShared1ディレクトリに移動することをテストしました。権限エラーはこれを防ぎ、時にはそれがDolphinをクラッシュさせます。
端末でテキストファイルを移動しても同じ結果を表示できます。
[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ではなくなりますが、その後user1になります。そしてuser3を体験してください。問題のない唯一のユーザーは、マウント仕様で使用されているユーザーです。 （私はallow_otherマウントオプションがこれを防ぐことを期待していましたが、それはできません。また、マウント仕様でrootを使用しても役に立たないようです。）
マウントオプションdefault_permissionsを削除すると、これらのエラーはなくなりますが、すべての権限チェックもなくなります。どのグループのユーザーもShared1でファイルを読み書きできますが、要件を満たしていません。
sftp-server 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
クライアントとサーバーの両方で2017年5月25日付けのOpenSSH_7.5p1、OpenSSL 1.1.0fが実行されています。これは最新バージョンのようです。
サーバーでは、systemctl status sshdはメインPID：4853（sshd）を示します。メインプロシージャステータスは、022のumaskを示しています。ただし、以下のsftpサブシステムのプロセス情報を提供します。これは、006の正しいumaskを示しています。
# 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-serverプロセスを確認する必要があります。予想される006のumaskが表示されます。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ビット（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
一般的な解決策は、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オプションは、誤って処理される基本的なFuseレイヤーにまで及びます。助言はそれを避けることです。 – RalphRönnquist16年6月17日7:56 sshfsとumaskについて
- https://jeff.robbins.ws/articles/setting-the-umask-for-sftp-transactions
- https://unix.stackexchange.com/a/289278/1501
編集：
このソリューションはコマンドラインと一部のデスクトップアプリ（KDEのKateテキストエディターなど）では機能しますが、多くのデスクトップアプリケーション（KDEのDolphinファイルマネージャー、XSaneなど）では正しく機能しません。したがって、これは良い全体的なソリューションではないことがわかりました。
sftp-serverが使用されている場合、/etc/profileの-maskは使用されません。 pam_umaskモジュールを使用して、すべてのユーザーセッション（シェルを含む）にmaskを設定できます。 /etc/pam.d/system-loginに追加：
session optional pam_umask.so
そして、/etc/login.defsにumask値を設定します。