umask / PAM / permissionsを完全に制御する方法は?


11

// 2月8日更新-未解決の問題の概要:

  • ディレクトリをファイルとは異なる方法でマスク解除する方法は?
  • Nautilusのコピー/貼り付けをumaskする方法は?
  • SSHFSのumaskを設定する方法は?

私たちの状況

当社の数人がサーバーにログインしてファイルをアップロードします。それらはすべて、同じファイルをアップロードおよび上書きできる必要があります。それらは異なるユーザー名を持ちますが、すべて同じグループの一部です。ただし、これはインターネットサーバーであるため、「他の」ユーザーには(一般に)読み取り専用アクセス権が必要です。だから、私が欲しいのはこれらの標準的な許可です:

ファイル:664
ディレクトリ:771

私の目標は、すべてのユーザーが権限を心配する必要がないことです。サーバーは、これらの権限がすべてのファイルとディレクトリに適用されるように、新しく作成、コピー、または上書きされるように構成する必要があります。特別な許可が必要な場合にのみ、これを手動で変更します。

サーバーにファイルをアップロードするには、NautilusのSFTP-ing、sshfsを使用してサーバーをマウントし、Nautilusでローカルフォルダーであるかのようにアクセスし、コマンドラインでSCP-ingを実行します。それは基本的に私たちの状況と私たちがやろうとしていることをカバーしています。

今、私は美しいumask機能について多くのことを読みました。私が理解していることから、umaskは(PAMと一緒に)私が望むことを正確に行えるようにするはずです。つまり、新しいファイルとディレクトリに標準の許可を設定します。しかし、何時間もの読書と試行錯誤の後、私はまだこれを機能させません。多くの予期しない結果が得られます。私はumaskをしっかりと把握し、多くの質問に答えていないのが本当に好きです。これらの質問を、私の調査結果とこれらの質問につながった私の試験の説明とともに、以下に投稿します。多くのことが間違っているように見えるので、私はいくつかのことを間違っていると思います。したがって、多くの質問があります。

注:Ubuntu 9.10を使用しているため、sshd_config変更してSFTPサーバーのumaskを設定できません。インストール済みのSSH OpenSSH_5.1p1 Debian-6ubuntu2 <OpenSSH 5.4p1が必要。それでは、質問に行きましょう。

1.効果を得るためにPAMの変更を再開する必要がありますか?

これから始めましょう。非常に多くのファイルが関係していたため、PAMの変更を有効にするためにシステム全体を再起動する必要があるかどうかもわからなかったため、何が影響を及ぼし、何が影響を与えないかを把握できませんでした。期待した結果が表示されなかった後にそうしましたが、これは本当に必要ですか?または、サーバーからログアウトしてログインし直すだけで、新しいPAMポリシーを有効にする必要がありますか?または、リロードする「PAM」プログラムがありますか?

2.すべてのセッションのすべてのユーザーに影響を与える変更する単一のファイルはありますか?

だから私は多くの異なるものを読んで、多くのファイルを変更することになりました。私は次のファイルにumaskを設定することになりました。

~/.profile -> umask=0002
~/.bashrc -> umask=0002
/etc/profile -> umask=0002
/etc/pam.d/common-session -> umask=0002
/etc/pam.d/sshd -> umask=0002
/etc/pam.d/login -> umask=0002

この変更をすべてのユーザーに適用したいので、何らかのシステム全体の変更が最適です。達成できますか?

3.結局のところ、このことはうまくいきますか?

そこで、可能なすべての場所でumaskを0002に変更した後、テストを実行します。

------------ SCP -----------

テスト1:

scp testfile (which has 777 permissions for testing purposes) server:/home/
testfile                                      100%    4     0.0KB/s   00:00   

許可を確認しましょう:

user@server:/home$ ls -l
total 4
-rwx--x--x 1 user uploaders 4 2011-02-05 17:59 testfile (711)

更新:pam.d / common-sessionsでumaskを設定するだけで修正(コメントを参照)

--------- SSH ------------

テスト2:

ssh server
user@server:/home$ touch anotherfile
user@server:/home$ ls -l
total 4
-rw-rw-r-- 1 user uploaders 0 2011-02-05 18:03 anotherfile (664)

-------- SFTP -----------

Nautilus:sftp:// server / home /

クライアントからサーバーへの新しいファイルのコピーと貼り付け(クライアント上の777)

テスト3:

user@server:/home$ ls -l
total 4
-rwxrwxrwx 1 user uploaders 3 2011-02-05 18:05 newfile (777)

Nautilusを使用して新しいファイルを作成します。ターミナルでファイルのアクセス許可を確認します。

テスト4:

user@server:/home$ ls -l
total 4
-rw------- 1 user uploaders    0 2011-02-05 18:06 newfile (600)

つまり...ここで何が起こったのですか?!我々はすべき 644毎回取得します。代わりに、711、777、600、その後644を取得します。また、644は、最も可能性の低いシナリオであるSSHを介して新しい空のファイルを作成する場合にのみ達成されます。

だから私は尋ねています、結局umask / pamは動作しますか?

更新:pam.d / common-sessionsにumaskを設定するだけでテスト4を修正(コメントを参照)

4.それがUMASK SSHFSにとって何を意味するのでしょうか?

時々、sshfsを使用してサーバーをローカルにマウントします。非常に便利。しかし、再度、権限の問題があります。

マウント方法は次のとおりです。

sshfs -o idmap=user -o umask=0113 user@server:/home/ /mnt

注:明らかに、sshfsは666ではなく777から始まるので、umask = 113を使用します。したがって、113では、目的のファイル許可である664が得られます。

しかし、今起こっているのは、すべてのファイルとディレクトリが664のように見えることです。Nautilusで/ mntを参照し、

  • 右クリック->新規ファイル(newfile)--- テスト5
  • 右クリック->新規フォルダー(newfolder)--- テスト6
  • ローカルクライアントから777ファイルをコピーして貼り付けてください--- テスト7

コマンドラインで確認しましょう:

user@client:/mnt$ ls -l
total 8
-rw-rw-r-- 1 user 1007    3 Feb  5 18:05 copyfile (664)
-rw-rw-r-- 1 user 1007    0 Feb  5 18:15 newfile (664)
drw-rw-r-- 1 user 1007 4096 Feb  5 18:15 newfolder (664)

しかし、ちょっと、サーバー側でこの同じフォルダーをチェックしましょう:

user@server:/home$ ls -l
total 8
-rwxrwxrwx 1 user uploaders    3 2011-02-05 18:05 copyfile (777)
-rw------- 1 user uploaders    0 2011-02-05 18:15 newfile (600)
drwx--x--x 2 user uploaders 4096 2011-02-05 18:15 newfolder (711)

何?!REALファイルのパーミッションは、Nautilusで見られるものとは大きく異なります。sshfsのこのumaskは、非現実的なファイル許可を示す「フィルター」を作成するだけですか?そして、私は別のユーザーからファイルを開こうとしましたが、同じグループは実際の600のアクセス許可がありましたが、644の「偽の」アクセス許可があり、まだこれを読むことができませんでしたので、このフィルターは何が良いですか?

5. UMASKはすべてファイルに関するものです。しかし、ディレクトリについてはどうですか?

私のテストから、適用されているumaskも何らかの方法でディレクトリのアクセス許可に影響を与えることがわかります。ただし、ファイルを664(002)、ディレクトリを771(006)にする必要があります。ディレクトリに異なるumaskを使用することは可能ですか?

6. PERHAPS UMASK / PAMは本当にクールですが、UBUNTUはちょうどおかしいですか?

一方では、PAM / UMASKとUbuntuで成功した人々のトピックを読みました。その一方で、Ubuntuのumask / PAM / fuseに関する多くの古いバグと新しいバグを見つけました。

それで、私はもう何を信じるべきかわかりません。あきらめるだけですか?うACLはすべての私の問題を解決しますか?または、Ubuntuの使用で再び問題が発生しますか?

tarを使用したバックアップに関する注意事項。Red Hat / CentosディストリビューションはtarプログラムでACLをサポートしていますが、Ubuntuはバックアップ時にACLをサポートしていません。これは、バックアップを作成するとすべてのACLが失われることを意味します。

Ubuntu 10.04にアップグレードしても問題が解決する場合は喜んでアップグレードしますが、まず何が起こっているのかを理解したいと思います。

回答:


3

ここで多くのことが起こっている可能性があります。

最初の考え:

  • はい、pam.dの変更はすぐに有効になります
  • /etc/pam.d/common-session デフォルトを設定するのに最適な場所です umask
  • どんなのpam.dのumaskがで任意のエントリで上書きになるだろう.bashrc
    しかし、.bashrc唯一の特定の状況(対話型、非ログインシェル)の下で読んでます
  • testfile (711) とても奇妙です
    • /homeマウント方法、およびACLを使用していますか?
      (たとえば、何ls -ld /homegetfacl /home印刷しますか?)
    • でしたtestfileあなたはコピーをした前ので、既に、存在してscpすでに存在するファイルのパーミッションを変更することはありません(あなたが使用しない限り-pフラグ)
  • Nautilusは別の方法でファイルを作成することが知られていますが、その理由やルールはわかりません
  • umask=0113 おそらく問題を引き起こすでしょう
  • サーバーとクライアントは同じオペレーティングシステムを実行していますか?
    たとえば、クライアントでACLが有効になっている場合、またはCygwinの場合、動作は異なる可能性があります
  • 正気のパーミッションを強制する最善の方法は、デフォルトのACLを使用することです。なぜなら、あなたが発見umaskしたように、.bashrcとのユーザーがオーバーライドできるから.bash_profileです。

更新:

  • umask=0113 sshfsが間違っています。
    1. 指定せずにマウントしてみてください umask
    2. を使用して、マウントポイント内に新しいファイルを作成しますtouch
    3. たとえば-rw-r--r--xビット なしでのみ取得されるはずです。
    4. xビットをマスクすることにより、ディレクトリが破損し
      、コンパイラが実行可能ファイルを適切に作成できない場合があります

回避策:

これ以上何も考えられない場合は、使用するfamgamin、作成される新しいファイルを監視してそれらのアクセス許可を修正するか、定期的に実行してすべてのファイルにアクセス許可を設定するスクリプトを使用することができます。


ありがとう!それでは、pam.d / common-sessionsを除くすべての umask設定を削除しました。これでいくつかの問題が解決しました!テスト1(SCP)およびテスト4(Nautilusの新しいファイル)が正常に機能するようになりました。ハードルは、サーバーにNautilusのすべての権限でファイルをコピーしています(テスト3-まだ664ではなく777)。そして、ディレクトリの問題。サーバーとクライアントはどちらもUbuntu(9.10対10.10)であり、追加のACLは有効になっていません。

ノーチラスとコピーのような音は次のように権限を保持しているcp -pscp -pだろう。
ミケル

これを変更する方法はありますか?

どのような振る舞いがしたいですか?デフォルトACLを使用して、新しいファイルにデフォルトの許可を設定できます。NautilusはデフォルトのACLを尊重します。概要についてはvanemery.com/Linux/ACL/linux-acl.htmlを、すべての詳細についてはsuse.de/~agruen/acl/linux-acls/onlineを参照してください。
ミケル

デフォルトのACLは、許可の最大セットを強制するのではなく、それらの許可をデフォルトにするだけであることに注意してください。 cp -pscp -p、およびノーチラス経由でコピーすることは、まだコピーされたファイルとしてコピーの許可を同じにしようとします。
ミケル

0

これはPAM / umask関連ではありませんが、役に立つかもしれません。

あなたがいる場合setgidをディレクトリを、それの内部で作成されたすべてのファイルとディレクトリは、自動的にそのグループに割り当てられています。

root@ricarda ~ # mkdir hello      
root@ricarda ~ # chown :users hello 
root@ricarda ~ # chmod g+s hello
root@ricarda ~ # ls -l |grep hello 
drwxr-sr-x. 2 root users  4096 Feb  7 04:05 hello
root@ricarda ~ # touch hello/some_file
root@ricarda ~ # mkdir hello/some_dir
root@ricarda ~ # ls -l hello/       
total 4
drwxr-sr-x. 2 root users 4096 Feb  7 04:16 some_dir
-rw-r--r--. 1 root users    0 Feb  7 04:06 some_file

ありがとう!私はこれについて知りませんでした。許可の問題を解決するわけではありませんが、実際に役立ちます!


0

ACLは正常に機能するはずです。

グループのすべてのフォルダーにデフォルトACLを設定します。これは、将来のすべてのファイルとディレクトリに継承されます。

のような何かが動作するsetfacl -m d:g:uploaders:rwxはずです。

既存の権限を修正するには:

find /shared/folder -type d -exec setfacl -m d:g:uploaders:rwx {} \;
find /shared/folder -type f -exec setfacl -m g:uploaders:rw {} \;

ただし、ファイルのコピー時に「保持」が設定されている場合、デフォルトのACLは機能しません。その場合、cronでfindコマンドを実行するか、ファイルシステムの変更を監視することしかお勧めできません。

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