私の脳の中のどこかでmake
rootにコンパイル(つまり実行)しないように警告するインターネット音声警告を読んだ覚えがあります。おそらくこれです。この物語cprogramming.com.
同時に、root ユーザーが/usr/local
そのサブディレクトリを所有することが一般的に推奨されます。
これにより、ソースからソフトウェアをインストールするのが面倒になります。
# as root
mkdir program
chown user.user program
# as user
wget/curl/mv program.tar.gz program/.
cd program/
./configure --prefix=/usr/local
make
# as root
make install
これがソースからシステム全体にソフトウェアをインストールする最も簡単で正確な方法ですか?make
ルートになるのは本当に危険ですが、make install
そうではありませんか?
答え1
リスクを減らすことが重要です。make
破壊的な操作が実行されると、それを実行しているユーザーが変更(または削除)できるデータのみが失われます。したがって、make
そのユーザーのファイル範囲を制限するために通常のユーザーとして実行し、通常のインストールにはこれを行う必要があるため、通常のユーザーmake install
として実行します。root
/usr/local
提供された例では、タールボールをホームディレクトリまたは書き込むことができる他のディレクトリにダウンロードして解凍し、一般ユーザーとして構成してビルドするprogram
必要はありません。root
$ wget ...
$ tar xf program...tar.gz
$ cd program...
$ ./configure --prefix=/usr/local
$ make
通常はデフォルトの/usr/local
プレフィックスなので省略できます。
セキュリティを最大化するには、ソフトウェアを構築するための専用ユーザーを使用し(何が間違ってもファイルを失うことを避けるため)、少なくともビルドシステムをお読みください。make -n
役に立つかもしれません:実際に何もせずに何ができるかを見せてください。書き込み権限を持つ特別なユーザーまたはグループを作成し、/usr/local
それを実行時に使用することもできますmake install
。
答え2
それは信頼と利便性につながります。もちろん、make
不安を感じることも可能ですが、そうかもしれませんmake install
。ただ表面攻撃領域が(希望的に)より小さくなければならず、一目で奇妙なことが明らかになるmake install
可能性が高いです。Makefile
しかし、$PATH
ソフトウェアをインストールすることは誰がコンパイルしても危険なので、質問全体は議論の余地があります。
個人的には、私はしばしば自分と他の管理者をstaff
そのグループに入れ、そのグループに権限を与えます/usr/local
。これにより、ルートがまったく必要なくゲームをプレイし、tar
バイナリのconfigure
インストールを支援できます。make
sudo
いいえ、完璧ではありません。はい、とても便利です。