/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によってのみ呼び出されます。
/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の所有者を変更するよりも優れたソリューションだと思います。