1つのファイルが2人のユーザーに属することを望んでいます。どうやって?ハードリンクが失敗する


32

2つのsetuidプログラム/usr/bin/bar/usr/bin/bazは、単一の構成ファイルを共有しますfoo。構成ファイルのモードは0640、機密情報を保持するためです。1つのプログラムは次のように実行されますbar:bar(つまり、ユーザーバー、グループバーとして)。他としてbaz:bazユーザーを変更することはオプションではなく、グループを変更することも好ましくありません。

/etc/bar/fooおよびとして単一の構成ファイルをハードリンクしたいと思います/etc/baz/foo。ただし、ファイルは、私が知る限り、root:barまたはのいずれかに属している必要があるため失敗しますroot:baz

潜在的な解決策:barbazメンバーがbarおよびである新しいグループを作成しますbaz。にfoo属しroot:barbazます。

それは私にとってはかなり手間のかかる解決策のように見えます。foo2つのプログラム間で構成ファイルを共有するためのより簡潔で簡単な方法はありませんか?

今のところ、ファイルの同一のコピーを2つ保持しています。これは機能しますが、明らかに間違っています。何が正しいでしょうか?

情報:Unixグループの経験はほとんどなく、setgid(2)の経験はありません。


質問は一般的に段階的です。私の場合、2つのプログラムはたまたまExim4とDovecotであり、パスワードとTLS証明書を共有できるメール処理プログラムです。
thb

8
このためのUbuntu(およびDebianだと思います)ソリューションはssl-certグループであり、ほとんどあなたのbarbazグループです。標準では、すべての秘密鍵をssl-certグループが所有するように設定し、それらにアクセスする必要があるプログラムに関連付けられたUIDをそのグループに入れます。
-abligh

1
@abligh:興味深い。私のシステムはDebian 8 jessieです。どうやら、ssl-certインストール時にpostinstスクリプトがユーザーのグループを作成するパッケージが存在するようです。私は知らなかったssl-cert。Apache2(ホストにインストール済み)が推奨し ssl-certます。さまざまなEximおよびDovecotパッケージはサポートしていませんが、Postfix(ホストにインストールされていない)はに依存していssl-certます。Apacheのため、私のホストにはssl-certグループがありますが、このグループにはまだメンバーがいません。アドバイスをありがとう。
-thb

5
プログラムをsetuidではなくsetgidにします。Setuidプログラムは、危険にさらされた場合、バイナリを置き換えてトロイの木馬を作成できるため、悪い考えです。(例外:setuid rootで、あなたは選択肢がありませんので。)
ジル「SO-停止されて悪」

1
DOES wiki.dovecot.org/HowTo/EximAndDovecotSASLはあなたの特定の状況を解決しますか?
MvG

回答:


50

ACLを使用して、両方のグループのユーザーがファイルを読み取れるようにすることができます。

chgrp bar file
chmod 640 file
setfacl -m g:baz:r-- file

これでbarbazグループとグループの両方がファイルを読み取ることができます。

たとえば、モード640のbin:binが所有するファイルを次に示します。

$ ls -l foo
-rw-r-----+ 1 bin bin 5 Aug 17 12:19 foo

+ACLセットがあるという意味なので、見てみましょう。

$ getfacl foo
# file: foo
# owner: bin
# group: bin
user::rw-
group::r--
group:sweh:r--
mask::r--
other::---

行を見ることができますgroup:sweh:r--:これは、グループの人々がswehそれを読むことができることを意味します。

こんにちは、私です!

$ id
uid=500(sweh) gid=500(sweh) groups=500(sweh)

はい、ファイルを読むことができます。

$ cat foo
data

23

次のステートメントを再検討することをお勧めします。

考えられる解決策:メンバーがbarおよびである新しいグループbarbazを作成しますbaz。にfoo属しroot:barbazます。

それは私にとってはかなり手間のかかる解決策のように見えます。foo2つのプログラム間で構成ファイルを共有するためのより簡潔で簡単な方法はありませんか?

新しいグループを作成するのはなぜ重いのですか?これを行うと、ACLよりも次の利点があります。

  • これはコマンド/usr/bin/bar/usr/bin/bazで架空のものとして表現していますが、これら2つのプログラムが構成ファイルを共有できることは重要です。これは、プログラムが自然に関連していることを示唆しています。それらの新しいグループを作成すると、実際に存在し、動作(一般的な構成ファイルを読み取るためのアクセス許可など)をトリガーする関係が記述されているように見えます。
  • グループを介してこの問題を解決することは、すべての Unixに移植可能です。つまり、UnixまたはUnixライクなシステムで、同じメカニズムに完全に同じ方法で依存することができます。ACLははるかに複雑であり、移植性が問題になる可能性があります。

個人的には、ACLはここでは手間のかかるソリューションであり、グループはより単純で伝統的なUnixの方法であると考えています。


16

これは、アクセス制御リスト(ACL)の一般的な使用方法だと思います。両方のユーザー(またはグループ)を構成ファイルのACLに追加します。

/etc/foo  root:root rw-------  # Traditional Unix ownership and permission for foo
$ setfacl -m user:bar:rw- / etc / foo#ユーザーバーがfooを読み書きできるようにする
$ setfacl -m user:baz:rw- / etc / foo#ユーザーbazによるfooの読み書きも許可します

最初にacl-packageをインストールする必要がある場合があります。


3

ファイルのモード0660(または0440書き込みが不要な場合でも)およびownerを作成しbar:bazます。次に、1つのプロセスがユーザーのアクセス許可のおかげでファイルにアクセスでき、もう1つのプロセスがグループのアクセス許可のおかげでアクセスできます。これは、ACLが機能しないファイルシステムでも機能します。


2

まだ言及されていないのでこれを提出します。これはおそらくあなたが望んでいるものではありませんが、同様の質問を持つ他の人にとっては答えかもしれません。

「新しい」「クラウド」の方法は、すべての構成を構成管理システム(chefpuppetansibleなど)で処理することです。サーバー上に2つの異なるが同一のファイルがあることは問題ではありません。どちらも構成管理システムからの単一ファイルのコピーだからです。

このようにすることの主な利点は、構成が(他のすべての構成とともに)バージョン管理され、新しい同一またはほぼ同一のサーバーの展開が非常に簡単になり、otを自動化できることです。

(記録については、構成管理を使用していないため、@ drgの回答のようにグループシステムを使用します)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.