20コンピューティングノードから98,000コンピューティングノードまで、サイズが約40のクラスター上で数千人のユーザーがアプリケーションを実行している環境があります。これらのシステムのユーザーは、従来のUNIXアクセス許可によって制御される大規模なファイル(1PBを超える場合もあります)を生成します(ファイルシステムの特殊な性質のため、ACLは通常、利用できないか実用的ではありません)。
現在、「give」と呼ばれるプログラムがあります。これは、グループの権限が不十分な場合に、ユーザーが別のユーザーにファイルを「与える」ことができるsuid-rootプログラムです。したがって、ユーザーは次のように入力してファイルを別のユーザーに提供します。
> give username-to-give-to filename-to-give ...
次に、受信ユーザーは「take」(giveプログラムの一部)と呼ばれるコマンドを使用してファイルを受信できます。
> take filename-to-receive
次に、ファイルの権限が受信ユーザーに効果的に転送されます。
このプログラムは何年も前から存在しており、セキュリティと機能の観点から再検討したいと思います。
私たちの現在の行動計画は、「give」の現在の実装におけるビットの腐敗を取り除き、それを本番環境に再デプロイする前にオープンソースアプリとしてパッケージ化することです。
従来のUNIXアクセス許可しか利用できない場合に、ユーザー間で非常に大きなファイルを転送するために使用する別の方法を持っている人はいますか?
エミッターが実際にファイルを提供する用意がある場合は、SUIDバイナリを使用して、すべてのユーザーが書き込み可能でスティッキービット(_/tmp
_など)があるディレクトリにファイルを移動し、所有権を新しい所有者に変更します。 。 chown(3)
は、_set-user-ID
_および_set-group-ID
_ビットの削除をすでに処理しています。このようにして、新しい所有者は、ファイルの移動を含め、ファイルに対して必要なことを実行できます。
すべてのユーザーが書き込み可能なこのディレクトリは、ホームディレクトリに複数のファイルシステムを使用し、ファイルシステムの境界を越えないようにして、パフォーマンスがすぐに低下する場合に備えて、ユーザーのホームディレクトリに属することができます。この場合、新しいファイルが提供されたときに受信者がそれを確実に認識できるようにする必要があります。
電子メールでうまくいくでしょう。よりUnixyなソリューションは、新しく配信されたファイルをリストする_/etc/profile
_です。この機能を_pam_echo
_で提供するとボーナスが追加されます(egと_file=/tmp/deliveries/%u
_、pam_echo(8)
を参照)。 PAM関連の場合と同様に、すべての実装がそのようなモジュールを最初に提供していることを確認する必要があります。
Xryl669が言うように、実際にファイルを共有するためにディレクトリを使用できます。次のようになります。
$ ls -ld shared
drwxrws--- 2 root usergroup 4096 somedate shared
$ ls -l shared
drwx-wx--- 2 user1 usergroup 4096 somedate user1
drwx-wx--- 2 user2 usergroup 4096 somedate user2
drwx-wx--- 2 user3 usergroup 4096 somedate user3
drwx-wx--- 2 user4 usergroup 4096 somedate user4
Giveコマンドは
#!/bin/sh
#Use a random suffix to prevent guessing
RANDOM=$(dd if=/dev/urandom count=4 2> /dev/null | sha512sum | cut -d' ' -f1)
NEWNAME=/path/to/shared/$2/$1$RANDOM
#Move the file
mv $1 $NEWNAME
#Make it readable
chmod 440 $NEWNAME
Takeコマンドは次のようになります。
$ cd /path/to/shared/user
$ ls
...
$ mv somefile ~
これはおそらく役に立たないでしょうが、参考までにcp --reflink source targetは、コピーオンライトを使用してファイルのシンコピーを実行します。
つまり、ファイルを完全にコピーでき、変更されたブロックのみが実際にコピーされます。ハードリンクとは異なり、新しいファイルには独自のiノードとメタデータがあり、標準のchownを使用してファイルのコピーを新しいユーザーに提供できます。
私の知る限り、これは現在OCFS2とbtrfsでのみ利用可能な機能です。私はそれであなたの問題は解決すると思いますが、それの利用可能性が広まっているわけではないので、それはおそらく役に立たないでしょう。
アプリを書き直して、実際に「与える」と「取る」を模倣することをお勧めしますが、保護されたディレクトリから「プッシュ」して「プル」します。ディレクトリは、ファイルの移動を処理するプッシュ/プルアプリでのみアクセスできます。または、アプリ/スクリプトは、送信者と受信者のみに権限が設定されたランダムな一時ディレクトリを作成できます。
セキュリティを強化したいですか? PGPでファイルを暗号化/署名できます(受信者の公開鍵を使用)。
「セキュリティと機能の観点」からのやり直しという点では、SUIDプログラムを作成することを強くお勧めしますnot。適切な方法で特権を削除しない場合は、システム上の任意のファイルに仮想的にアクセスできます。プログラムにバグがある場合(バッファオーバーフローなど)-これを悪用して、システムのルートアクセスを取得できます。
共有ディレクトリを持つシステムを使用することもできます(おそらく実行権限がない可能性があります)。この場合、特定のユーザーのものが特定のファイル名構造(たとえば、to-$username_from-$username.tar
)でアーカイブされます。 Giveはファイルを作成し、chowns
それをターゲットユーザーに渡します。 takeはファイルを抽出して削除します。
実際に移動する場合(つまり、ファイルの場所とアクセス許可を変更します。ファイルサイズが大きいためコピーしないでください)、-x permsを使用して共有ディレクトリに移動することで問題を回避できる場合があります(したがって、誰もできません)そこにファイルをリストします)、そして同じchown
メソッド。 mv
、chown
/mv
。