`/ usr / local`をchownしても安全ですか？
/usr/localの目的を知っています-ローカルマシンにソフトウェアをインストールします。デフォルトでは、rootがディレクトリを所有しています。つまり、そこにインストールするには、Sudoを使用する必要があります。シングルユーザーまたは開発者のマシンの場合、これはコマンドの不必要な追加使用のように思われます。したがって、私の質問-/usr/localを所有しても安全ですか？
たとえば、OSbrew for Home Xは「_JOME WORKS」であり、/usr/localと安全にを所有しているため、Sudoを使用せずにソフトウェアをインストールします。
さらに、/usr/localにインストールされたローカルにコンパイルされたソフトウェアがある場合、ソフトウェアは現在、自分自身を変更するか、プラグインをインストールするためにrootを必要とします。これは安全ではないようです。正確に何が起こるかを知っているときにのみSudoを使用したいと思います。
ご意見？
/usr/localの所有者になることはお勧めできません。ほとんどの場合、おそらくSudoを使用するよりも安全性が低くなります。
あなたの質問は、chown/usr/localにしたい2つの理由を示唆しています。
1つ目は、Sudoを使用してソフトウェアをインストールする必要がないようにすることです。これは、一部の人（ this answer の作成者など）が効率的に作業したいと言ったり、Sudoを入力してパスワードを入力するのに必要なキーストロークを保存したりする場合があります。しかし、おそらく「不要」と言うときは、代わりに 最小特権の原則 を参照しています。
デフォルトでは、
rootがディレクトリを所有しています。つまり、そこにインストールするには、Sudoを使用する必要があります。シングルユーザーまたは開発者のマシンの場合、これはコマンドの不必要な追加使用のようです
「このシステムを使用しているのは私だけなので、Sudoを使用してパスワードを入力する必要はありません。」という行に沿って意見や不満を言う人々をよく耳にします。その見解を持っている読者のために、そしてそれがここで関連しているので、物事を所有するためのルートの基本的なセキュリティ上の理由を思い出してみましょう。
Ubuntuシステムにインストールされたプログラムファイルのほとんどは、ファイルモード755、または記号表記rwxr-xr-xを持ちます。つまり、すべてのユーザーまたはプログラムが実行可能ですが、ファイルの所有者であるrootのみが変更できますそれら。 （技術的には、これは、ルート以外の誰もがそれらを含むディレクトリに対するwパーミッションを持たないことを必要とするため、他のユーザーはそれらを削除または移動できません。）
これは、謙虚なユーザーであるあなたが任意のプログラムを実行できることを意味します。 rootが所有するファイルに対して書き込み操作を実行するなど、実行する権限のない何かを行うためにプログラムを使用しようとすると、エラーが発生します。これにより、一部のコマンド、バグのあるアプリケーション、または悪意のあるコードのタイプミスにより、システムが混乱する可能性が低くなります。rootとして実行している場合を除き、実行する権限がありません。これは、インターネットと対話するプログラムを実行するときに特に役立ちます。
chown/usr/localの場合、any権限で実行しているプログラムはそこにファイルを書き込むことができ、同じ名前の別のコマンドを置き換えるなど、何らかの理由でrootとして実行される可能性があります。 /usr/local/binはデフォルトの $PATH にあり、Sudoの- secure_path にあり、それはbefore両方の他の場所。したがって、2つの実行可能ファイルがある場合
/usr/local/bin/chown
/bin/chown
Sudo chown ...を実行すると、/usr/local/binのchownが実行されます。
しかし、2番目の理由はセキュリティに関するものであるため、おそらくすでにすべてを知っているでしょう。
さらに、ローカルでコンパイルされたソフトウェアを
/usr/localにインストールしている場合、ソフトウェアは現在、自分自身を変更したりプラグインをインストールしたりするためにルートが必要です。これは安全ではないようです-知っているときだけSudoを使いたい正確に何が起こるか.
ここで言及する必要がある場合に備えて、ローカルでコンパイルされたソフトウェアを/usr/localにインストールすることは（とにかくFHSによれば）絶対に正しいことですが、コンパイルは最後のステップまでSudoなしで$HOMEのどこかで行う必要がありますSudo make installまたは同等のものを入力したとき。
/usr/localにインストールされたプログラムをその非特権所有者として実行することにより、自分自身を更新しようとしたときにスローされる特定の許可エラーを使用して、自分が所有していない他のファイルシステムの場所を変更しようとしていることを示唆していると思いますあなたが望んでいないので、そうすることを止めることができます。
これはmight役に立ちます。これは、プログラムが/usr/local内で好きなことを行うことを信頼しているが、他の場所ではないことを意味します。昇格されたアクセス許可を要求する場合は、更新またはアンインストールを許可することを拒否できます。それは私には理にかなっています。しかし、このような方法で/usr/localを一種のサンドボックスとして使用しようとすることは、おそらく良い考えではないか、少なくとも最も安全なソリューションではないでしょう。適切に分離された場所ではありません（デフォルトの/optにないため、$PATHはもう少し分離されています）。プログラムは、/usr/localに何かを書き込んだり削除したりして、害を及ぼす可能性があります。実行する他の（潜在的に記述が不十分な）プログラムは、知らないコードを記述して実行する可能性があります。
プログラムが自分自身を安全に更新できるようにすることが心配な場合は、おそらく代替手段を探す必要があります（たとえば、pythonのように、プログラムに固有のもの、またはスナップまたは同様の実装を探すことができますニーズに合っているか、コンテナまたはVMを使用して安全でない可能性のあるソフトウェアをテストしてから、通常のユーザーが実行するプログラムによって書き込まれるシステムの場所（比較的ユーザーが多い場所でも）を公開します。これは、Sudoを使用して一時的に権限を昇格させたプログラムを許可するのと同じように、予測できない影響を与える可能性が高いように思えます。
/usr/localがrootによって所有されていないことはまれです。ただし、必要に応じて所有者を変更できます。
ただし、セキュリティ問題を回避するために、/usr/local/sbinがrootによって所有されていることを確認することをお勧めします。ここでのコマンドは通常、rootによってのみ呼び出されます。
ソフトウェアのみyouが必要な場合は、/usr/localの代わりにホームディレクトリを使用してください。
/usr/localの所有権を変更したり、不要な場合にrootとしてコマンドを実行したりする代わりに、ビルドを構成して、/usr/localではなくホームディレクトリにインストールする必要があります。これにより、binおよびsbinサブディレクトリがrootのパスにどのように含まれるかなど、/usr/localの所有権を変更することで発生する可能性のあるすべての問題に対処します。
他のユーザーにソフトウェアの実行を許可する必要がある場合は、アクセスを許可できます。実際には、デフォルトでホームディレクトリに 読み取りおよび実行の許可アクセス が設定されているため、おそらく既に可能です。 （それが望ましくない場合は、プライベートにしたいファイルまたはディレクトリで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の実行に慣れている場合がありますが、独自のホームディレクトリにインストールする場合、rootとして実行する必要はないため、-およびshould--Sudoを省略します。ただ走れ：
make install
同様に、uninstallターゲットをサポートするソフトウェアの場合：
make uninstall
これはまさにあなたが求めていたものです... /usr/localではなく、ホームディレクトリでのみ。
プログラムを実行する
Probablyホームディレクトリのbinサブディレクトリは次のいずれかです。
- すでに
$PATHにある、or - ログアウトしてから再度ログインすると、
$PATHになります。
その理由は、ホームディレクトリの.profileファイルには、ログイン時に実行されるコマンドが含まれていますが、Ubuntuのmost versionsで作成されたユーザーアカウントに対してデフォルトで含まれています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だったシステムをfromにアップグレードした場合、ホームディレクトリのbinサブディレクトリは既に$PATH。
.profileファイルは、ユーザーアカウントの作成時に/etc/skelディレクトリからコピーされます。ユーザーアカウントが古いUbuntuリリースで作成された場合、そのバージョンの.profileが取得され、ユーザーアカウントの場合は、より新しいリリースにアップグレードしても変更されませんでした。
ホームディレクトリのbinサブディレクトリが$PATHにあると、Ubuntuのパッケージマネージャーによってインストールされたプログラムまたは/usr/local内にインストールされたプログラムと同様に、名前を入力するだけで、実行可能ファイルがインストールされているプログラムを実行できます。
.localオプション
上記の16.04など、一部のUbuntuリリースで作成されたユーザーアカウントのデフォルトの.profileファイルは、パスに$HOME/binだけでなく$HOME/.local/binも追加することに気づいたかもしれません。 .profileがそれを追加しないが、wantに追加する場合、単純に編集することができます。
多くの場合、設定とキャッシュされたデータを保存するために使用されます ですが、ホームディレクトリの.localサブディレクトリ内にソフトウェアをインストールすることもできます。使いやすさとセキュリティの観点から、--prefix="$HOME/.local"は--prefix="$HOME"に似ているので、そうすることは禁止されていないと感じるはずです。
.で始まるファイルとディレクトリは、デフォルトではグラフィカルファイルブラウザに表示されないことに注意してください（ Ctrl+H （再表示して再表示する）またはlsコマンド（-Aまたは-aフラグを渡して表示）。これはあなたが望むものではないかもしれませんし、あなたが望むものそのものかもしれません。これは個人的な好みの問題です。
ただし、ソフトウェアをビルドしてホームディレクトリにインストールする自動化されたソースベースのパッケージマネージャーでは、$HOME/.localを使用していることがあります。これがどれほど一般的かは実際にはわかりません-さらに調査してこの回答を更新したいと考えていますが、手動でコンパイルするものには$HOMEを使用することをお勧めします。そうすれば、物事がどこから来たのかが明確になります。また、衝突が発生した場合でも、ソフトウェアは許容できる範囲で共存する可能性があります。
また、いくつかのソフトウェアを$HOME/.localに、他のソフトウェアを$HOMEに意図的にインストールすることもできます。それはあなた次第です。 $PATH環境変数で最初に表示されるbinディレクトリは、同じ名前のコマンドが両方に存在する場合にコマンドが実行されるディレクトリです。
クレジットは Zanna および Videonauth に エラーを指摘 で 以前のバージョン =この回答の、どのUbuntuリリースが.profileにどのデフォルトコードを持っているか、および 修正するのに役立ちます それら（ here も参照）
Sudoがこのような不便な場合は、/ etc/sudoersを更新するだけで、Sudoの実行時にパスワードを入力する必要はありません。これは、/ usr/localの所有者を変更するよりも優れたソリューションだと思います。