☰

仕える人:

tag-icon • tag-icon permissions acl sshfs
仕える人:

同じグループ（「チーム」）のユーザーがサーバー上で同じファイルを編集できるようにしたいと思います。これらのファイルを含むディレクトリはSSHFSを介してマウントされます。

これまでは、umask設定*を使用して目標を達成することはできません。それでは、ACLを試してみましょう。サーバーのディレクトリに次のデフォルトのACLを設定し、クライアントにインストールしました。

仕える人:

setfacl -d -m g::rwx .
[root@sshfsrv]# getfacl .
# file: .
# owner: user3
# group: team
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x

顧客：

sshfs -o allow_other,default_permissionsこのディレクトリはクライアントにインストールされ、許可されたオプションは許可されます。

クライアントにデフォルトのACLがなく、ファイルにグループに対する読み取りおよび書き込み権限がないため、グループ内のユーザーは同じファイルで作業できません。

[user3@client2]# getfacl .
# file: .
# owner: user3
# group: team
# flags: -s-
user::rwx
group::rwx
other::r-x

sshdを再起動し、クライアントからログアウトしてから再度ログインしました。setfaclクライアントでコマンドを実行しようとすると、「操作がサポートされていません」というメッセージで失敗します。

クライアントにデフォルトのACLがないのはなぜですか？

「チーム」グループのメンバーであり、クライアントPCにログインしているすべてのユーザーが、ローカルマウントビューを使用して同じリモートファイルセットに対して共同作業（読み取り/書き込み）できるようにするための目標を達成する他の方法はありますか？

アップデート1：

クライアントとサーバーの両方が、2017年5月25日にリリースされたOpenSSL 1.1.0fであるOpenSSH_7.5p1を実行しています。どちらもアーチLinuxを実行します。

サーバーにはsystemctl status sshdマスターPIDが4853（sshd）として表示されます。

# 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

/etc/ssh/sshd_config には次の Match 句があります。

Match Group team
  ForceCommand internal-sftp -u 0006

リクエストに応じて追加情報を提供できます。

アップデート2：

「チーム」グループのユーザーがリモートサーバーから（ローカルインストールを介して）同じファイルを編集（読み取りおよび書き込み）できるようにしたいと思います。

声明に詳細が必要です

以下の詳細をご覧ください。

SSHFSはどのユーザーをマウントしますか？

このグループteamには、user1、user2、user3という3人のユーザーが含まれています。どちらかをSSHFSとしてマウントできます。ただし、問題は常に他の2人のユーザーのアクセス許可/アクセスです。したがって、私の問題は、mountコマンドで指定されたユーザー以外のグループの他のユーザーに関連しています。 mountコマンドの変形を試しましたが、現在は次のようになります。

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

ローカルユーザーは、リモートサーバーの同じグループのユーザーにマップされていますか？

ユーザーとグループは同じIDを持っています。マッピングは必要ありません。

通常、SSHFSは悪いアイデアです（TCP衝突に対して脆弱です）。特に、複数のユーザーがそれを使用している場合はさらにそうです。

私は以前これについて聞いたことがありません。多くのスマートな人々がSSHFSをお勧めします。しかし、うまくいかないと、他の方法に切り替える以外に選択肢はありません…

IPSec経由のNFSのようなものを考えてみましたか？

私たちは10年間NFSを使用してきましたが、権限の面では決して満足のいくものではありません。一部の「専門家」はSSHFSに切り替えることを提案し、私たちはちょうどそうしました。彼はこれが私たちの許可の問題を解決すると述べた。これまでのところ、質問からわかるように変換はうまくいきませんが、ある程度の知識を持って問題を解決できることを願っています。まだSSHFSを放棄する準備ができていませんが、NFSに戻る必要がある可能性は常にあります。しかし、ユーザーの権限/アクセス管理の面では間違いなく満足できません。

あるいは、人々がファイルを直接編集できるようにするのではなく、Gitを使用することもできます。

Gitはこの状況に対する解決策ではありません。

脚注：

*コマンドラインテストではumask設定は正しく機能しましたが、デスクトップユーザーには機能しません。ファイルマネージャがファイルを移動できず、競合が発生し、複数のユーザーアプリケーションが間違った権限でファイルを保存しようとしたか、ファイルの保存にまったく失敗したことがわかりました。それは災いだった。

関連情報