// 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に関する多くの古いバグと新しいバグを見つけました。
- https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/241198
- https://bugs.launchpad.net/ubuntu/+source/fuse/+bug/239792
- https://bugs.launchpad.net/ubuntu/+source/pam/+bug/253096
- https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/549172
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314796
それで、私はもう何を信じるべきかわかりません。あきらめるだけですか?うACLはすべての私の問題を解決しますか?または、Ubuntuの使用で再び問題が発生しますか?
tarを使用したバックアップに関する注意事項。Red Hat / CentosディストリビューションはtarプログラムでACLをサポートしていますが、Ubuntuはバックアップ時にACLをサポートしていません。これは、バックアップを作成するとすべてのACLが失われることを意味します。
Ubuntu 10.04にアップグレードしても問題が解決する場合は喜んでアップグレードしますが、まず何が起こっているのかを理解したいと思います。