/usr/localローカルマシン用のソフトウェアのインストールの目的を知っています。デフォルトでrootは、ディレクトリを所有します。つまり、そこにインストールするには、を使用する必要がありますsudo。シングルユーザーまたは開発者のマシンの場合、これはコマンドの不必要な追加使用のようです。したがって、私の質問-私が所有しても安全/usr/localですか？
たとえば、OS X用のHomebrewは「Just Works」です。これは、を使用せずにソフトウェアを所有/usr/localして安全にインストールするためですsudo。
さらに、ローカルにコンパイルされたソフトウェアがにインストールされている/usr/local場合、ソフトウェアは現在、自分自身を変更するか、プラグインをインストールするためにルートが必要です。これは安全ではないようです- 何が起こるsudoかを正確に知っている場合にのみ使用したいと思います。
ご意見？
回答:
の所有者になることはお勧めできません/usr/local。ほとんどの場合、おそらくを使用するよりも安全性が低くなりsudoます。
あなたの質問はあなたが望むかもしれない2つの理由を示唆していchown /usr/localます。
1つ目は、sudoソフトウェアのインストールに使用する必要がないようにすることです。これは、一部（この回答の著者など）が効率的に作業したいというメッセージを読んだりsudo、パスワードの入力と入力に必要なキーストロークを保存したりする場合があります。しかし、おそらく「不要」と言うときは、代わりに最小特権の原則を参照しています。
デフォルトで
rootは、ディレクトリを所有します。つまり、そこにインストールするには、を使用する必要がありますsudo。シングルユーザーまたは開発者のマシンの場合、これはコマンドの不必要な追加使用のようです
「このシステムを使用しているのは私だけなのでsudo、パスワードを使用したり入力したりする必要はない」という意見に沿って、意見や不満を言う人をよく耳にします。その見解を持っている読者のために、そしてそれがここで関連しているので、物事を所有するためのルートの基本的なセキュリティ上の理由を思い出してみましょう。
Ubuntuシステムにインストールされたプログラムファイルのほとんどは、ファイルモード755またはシンボリック表記でrwxr-xr-x、すべてのユーザーまたはプログラムが実行できますが、ファイルの所有者であるrootのみがそれらを変更できます。（技術的には、root w以外のユーザーがそれらを含むディレクトリに対するアクセス許可を持たないようにする必要があるため、他のユーザーはそれらを削除または移動できません。）
これは、謙虚なユーザーであるあなたが任意のプログラムを実行できることを意味します。rootが所有するファイルに対して書き込み操作を実行するなど、実行する権限のない操作を行うためにプログラムを使用しようとすると、エラーが発生します。これにより、一部のコマンド、バグのあるアプリケーション、または悪意のあるコードのタイプミスがシステムを台無しにする可能性が低くなります。rootとして実行している場合を除き、実行する権限がありません。これは、インターネットと対話するプログラムを実行する場合に特に便利です。
あなたの場合はchown /usr/local、任意のあなたの権限で実行されているプログラムは、後に、このような同じ名前の別のコマンドに取って代わることなどによって、何らかの理由で、rootとして実行される可能性がありますされ、そこにファイルを書き込むことができます。/usr/local/binデフォルトであり$PATH、かつでsudoのsecure_path、そしてそれが来る前に、両方の他の場所。したがって、2つの実行可能ファイルがある場合
/usr/local/bin/chown
/bin/chown
実行するsudo chown ...と、chownin /usr/local/binが実行されます。
ただし、2番目の理由はセキュリティに関するものであるため、おそらくすでにすべてを知っているでしょう。
さらに、ローカルにコンパイルされたソフトウェアがにインストールされている
/usr/local場合、ソフトウェアは現在、自分自身を変更するか、プラグインをインストールするためにルートが必要です。これは安全ではないようです- 何が起こるsudoかを正確に知っている場合にのみ使用したいと思います。
念のためにそれはここにこれを言及する必要があります、それは絶対に右にローカルでコンパイルされたソフトウェアをインストールする（とにかくFHSによる）です/usr/localが、それ自体をコンパイルすることは、あなたの中にどこかを実行する必要があります$HOMEせず、sudo入力した最後のステップまで、sudo make installまたは同等。
/usr/local特権のない所有者としてインストールされたプログラムを実行することで、自分自身を更新しようとしたときにスローされる特定の許可エラーを使用して、あなたが所有していない他のファイルシステムの場所を変更しようとしていることを示唆していると思いますしたくないので、そうすることを止めることができます。
これは役に立つかもしれません。意味するところは、あなたがプログラムを信頼しているのは/usr/local、他の場所ではなく、内で好きなことをすることです。昇格されたアクセス許可を要求する場合、更新またはアンインストールを許可することを拒否できます。それは私にはいくらか理にかなっています。しかし/usr/local、このような方法でサンドボックスの一種として使用しようとすることは、おそらく良い考えではないか、少なくとも最も安全なソリューションになる可能性は低いと思います。適切に隔離された場所で/optはありません（デフォルトではないため、少し隔離されています$PATH）。プログラムは、何かを書き込んだり削除/usr/localしたりして害を及ぼす可能性があります。実行する他の（潜在的に記述が不十分な）プログラムは、知らないコードを記述して実行する可能性があります。
プログラムが自分自身を安全に更新できるようにすることを心配している場合は、おそらく代替手段を探す必要があります（たとえば、たとえばPythonのようにプログラムに固有のもの、またはニーズに合ったスナップまたは同様の実装を探すか、通常のユーザーが実行するプログラムによって書き込まれるシステムの場所（比較的ユーザーが多い場所であっても）を公開する前に、コンテナまたはVMを使用して潜在的に安全でないソフトウェアをテストします。これは、プログラムで一時的にアクセス許可を昇格することを許可するのと同じように、予測できない影響を与える可能性が高いように思えsudoます。
が/usr/local所有していないのは異常ですroot。ただし、必要に応じて所有者を変更できます。
ただし、セキュリティの問題を回避するために、/usr/local/sbinまだ所有されrootていることを確認することをお勧めします。ここでのコマンドは通常、rootによってのみ呼び出されます。
/usr/local/binそのroot（および他のユーザー）のコマンドは実行されますか？ルートが所有する必要はないでしょうか？さらに、rootが使用するコマンド-のコマンドを含む- /usr/local/sbinは、の共有ライブラリに依存する場合があります/usr/local/lib。これらのライブラリを変更すると、それらを使用するコマンドの動作に任意の変更が生じる可能性があります。/usr/local/sbinルートによって所有されたままであると主張することは、完全にarbitrary 意的なようです。
/usr/local。所有者を変更したり、/usr/local必要ないときにrootとしてコマンドを実行したりする代わりに、ビルドを設定して、の代わりにホームディレクトリにインストールする必要があります/usr/local。これは、アドレスの所有権を変更すると、すべての潜在的な問題/usr/localの方法を含め、binおよびsbinサブディレクトリをしているrootのパスを。
他のユーザーにソフトウェアの実行を許可する必要がある場合は、アクセスを許可できます。実際には、デフォルトでホームディレクトリに許可された読み取りおよび実行アクセス権があるため、それらはおそらく既に可能です。（それが望ましくない場合は、chmodプライベートにしたいファイルやディレクトリを使用して、場合によってはを変更するだけで、非常に簡単に変更できますumask。）
ソフトウェアがホームディレクトリにインストールされている場合、入っていたはずのバイナリ/usr/local/binが代わりに入れられます。インストールするソフトウェアに必要なサブディレクトリに対応する、ホームディレクトリの他のサブディレクトリを取得します。これは通常、ソースコードからソフトウェアをインストールするときに自動的に発生します。/home/username/bin/usr/local
ソースコードからビルドするほとんどのソフトウェアには、実行するステップがあります。
./configureそのconfigureように実行できるスクリプトが付属する大部分のソフトウェアでは、/usr/local最終的に実行sudo make installしてインストールするときに、内部でインストール用のビルドを構成するようにデフォルト設定されています。その理由は、実行と暗黙的に同等だからです：
./configure --prefix=/usr/localホームディレクトリにインストールするビルドを設定するには、代わりにこれを使用します：
./configure --prefix="$HOME"実際には、Ubuntuでは、ホームディレクトリパスにスペース、その他の空白、またはなどのシェルによって特別に処理されるその他の文字が含まれていない*ため、ユーザーアカウントを非常に奇妙に設定しない限り、次のように入力できます。
./configure --prefix=$HOME（しかし、スクリプトを書くための習慣を身に付けることはお勧めしません。また、macOSなどの他のOSでは、ユーザーのホームディレクトリへのパスにスペースが含まれることはあまりありません。）
または、ホームディレクトリの完全なパスを入力することもできます。
./configure --prefix=/home/username（usernameもちろん、実際のユーザー名に置き換えてください。何らかの理由でホームディレクトリが存在しない/home場合は、それに応じて調整する必要があります。）
あなたが実行した後make、あなたが実行しているに慣れすることができるsudo make installが、あなたがあなた自身のホームディレクトリにインストールするとき、あなたはあなたができるので、ルートとしてそれを実行する必要はありません-とすべきである --omit sudo。ただ走れ：
make install同様に、uninstallターゲットをサポートするソフトウェアの場合：
make uninstallこれはまさにあなたが求めていたものです...ただホームディレクトリではなく、/usr/localです。
おそらく、binホームディレクトリのサブディレクトリは次のいずれかです。
$PATH、または$PATHあなただけ後ろにログアウトした場合。その理由は、.profileログイン時に実行されるコマンドを含むホームディレクトリのファイルには、ほとんどのバージョンのUbuntuで作成されたユーザーアカウント（OSのインストール時に作成された初期管理者アカウントを含む）のデフォルトでこれが含まれているためです：
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fiそのコードは（ログインしているため）ログインすると実行され、その時点で存在する場合にのみ.profile個人binディレクトリを配置します$PATH 。そのため、ログアウトして再度ログインする必要があります。
Ubuntu 14.04のような古いリリースと、Ubuntu 17.10のような新しいリリースが付属しています。ただし、この記事の執筆時点でおそらく最も人気のあるリリースであるUbuntu 16.04には、代わりにこれがあります：
# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"これにより、binサブディレクトリだけでなくホームディレクトリのサブディレクトリもに追加さ.local/binれます$PATH。これらのディレクトリが実際に存在するかどうかはチェックされません。したがって、16.04を使用する場合、またはユーザーアカウントが作成されたときに16.04であったシステムからアップグレードした場合bin、ホームディレクトリのサブディレクトリは既ににあります$PATH。
あなたの.profileファイルをからコピーされ/etc/skel、ユーザーアカウントが作成されたときにディレクトリ。ユーザーアカウントが古いUbuntuリリースで作成された場合、そのバージョンが取得.profileされ、ユーザーアカウントの場合、より新しいリリースにアップグレードしても変更されませんでした。
一度binあなたのホームディレクトリのサブディレクトリは、あなたの中にある$PATH、あなたがUbuntuのパッケージマネージャあるいはインストールされた内部によってインストールされたプログラムで行うことができます同じように、単に自分の名前を入力して、その実行可能ファイルがインストールされているプログラムを実行することができます/usr/local。
.localオプション.profile上記の16.04など、一部のUbuntuリリースで作成されたユーザーアカウントのデフォルトファイルは$HOME/bin、パスだけでなくにも追加することに気づいたかもしれません$HOME/.local/bin。あなた.profileがそれを追加しないが、あなたがそれを望むなら、あなたは単にそれを編集することができます。
けれども、多くの場合、ストアの設定とキャッシュされたデータを使用し、あなたも内部のソフトウェアをインストールすることができ.local、あなたのホームディレクトリのサブディレクトリ。ユーザビリティとセキュリティの観点からは、--prefix="$HOME/.local"に似ているので、あなたはそうすることで抑制されないと感じるべき--prefix="$HOME"です。
で始まるファイルとディレクトリ.は、デフォルトではグラフィカルファイルブラウザ（非表示と再表示にCtrl+ Hを使用）またはlsコマンド（-Aまたは-aフラグを渡して表示）に表示されないことに注意してください。これはあなたが望むものではないかもしれませんし、あなたが望むものそのものかもしれません。これは個人の好みの問題です。
ただし、ホームディレクトリでソフトウェアをビルドおよびインストールする自動化されたソースベースのパッケージマネージャーが使用されていることを確認しました$HOME/.local。これがどれほど一般的であるかは実際にはわかりませんが、さらに調査してこの回答を更新したいと$HOME思いますが、手動でコンパイルするものに使用することを好むかもしれません。そうすれば、物事がどこから来たのかが明確になります。また、衝突が発生した場合、ソフトウェアは依然として許容可能に共存する可能性があります。
また、一部のソフトウェアをに意図的にインストールし$HOME/.local、他のソフトウェアをにインストールすることもでき$HOMEます。それはあなた次第です。どちらbinのディレクトリあなたの最初に表示される$PATH環境変数は、コマンドが両方で同じ名前が存在するコマンドという場合には、から実行することです。
クレジットに行くZannaとVideonauthのための誤りを指摘して、以前のバージョンのUbuntuのリリースがでているデフォルトのコードを持っているかに関して、この答えの.profile、および修正するために私を助けて（も参照してここに）。