Linuxでの `fakeroot`コマンドの必要性は何ですか
なぜfakerootコマンドが必要なのですか？単にSudoまたはsuコマンドを使用できないのでしょうか。
マンページは言う：
fakeroot-ファイル操作のroot権限を偽装した環境でコマンドを実行します
About.comさんのコメント：
偽のルート環境を与えます。このパッケージは次のようなものを有効にすることを意図しています：
dpkg-buildpackage -rfakerootつまり、パッケージビルドのrootになる必要をなくします。これは、LD_PRELOAD〜libfakeroot.so、getuid、chown、chmod、mknod、stat、...のラッパーを提供し、それによって偽物を作成しますルート環境。これを理解していない場合は、fakerootは必要ありません。
私の質問は、単純なsuまたはSudoが解決しないという特別な目的は何ですか？たとえば、ubuntuにインストールされているすべてのパッケージを再パックするには、次のコマンドを実行します。
$ fakeroot -u dpkg-repack `dpkg --get-selections | grep install | cut -f1`
次のように、fakerootの代わりにSudoまたはsuを使用して上記のコマンドを実行できますか？
$ Sudo dpkg-repack `dpkg --get-selections | grep install | cut -f1`
編集：
ランニング：
$ Sudo dpkg-repack `dpkg --get-selections | grep install | cut -f1`
私にこのエラーを与えます：
制御ディレクトリに不正なアクセス許可700があります（= 0755以上かつ0775以下でなければなりません）
なぜですか？
あなたがリモートサーバーで作業している開発者/パッケージメンテナーなどであると想像してください。パッケージの内容を更新して再構築し、kernel.orgからカーネルをダウンロードしてカスタマイズし、それを構築したい、などです。これらのことを行おうとすると、いくつかの手順でroot権限（UIDおよびGID 0）は、さまざまな理由（セキュリティ、見落とされている権限など）に対応します。ただし、root権限を取得することはできません。リモートマシンで作業しているためです（他の多くのユーザーにも同じ問題があります）。これがまさにfakerootが行うことです。それは、それらを必要とする環境に対して、有効なUIDおよびGIDを0に見せかけます。
実際には、実際のroot特権を取得することは決してありません（あなたが言及しているsuおよびSudoとは逆に）。
Fakerootと実際のSudo/suの違いを明確に見るには、次のようにします。
$ fakeroot
# echo "Wow I have root access" > root.tst
# ls -l root.tst
-rw-rw-r-- 1 root root 23 Oct 25 12:13 root.tst
# ls -l /root
ls: cannot open directory /root: Permission denied
# exit
$ ls -l root.tst
-rw-rw-r-- 1 ubuntu ubuntu 23 Oct 25 12:13 root.tst
Fakerootシェル内にいる限り、rootであるかのように見えます-root権限が本当に必要なことを何も実行しない限り。そして、これはまさに、どのマシンでも意味のあるパッケージを作成するためにパッケージツールが必要とするものです。
実際、パッケージ化にfakerootを使用する場合、達成したいことは、fakerootで実行するツールを作成して、ファイルがrootによって所有されていると見なすことです。それ以上でもそれ以下でもありません。したがって、実際には、suまたはSudoは適切なファイル所有権を取得するためには機能しません。
答えが（私には）理解しづらく、理解するのに少し考えが必要だった（ このコメント 理解させてくれた）ので、うまくいけばより良い説明をするつもりです。
1. fakerootで何が起こるか
自分のユーザーで何が起きるかだけです。絶対に何もない。 fakeroot（呼び出されたときに、Sudoのように新しいシェルが提供される）の場合、許可が必要なことを行うふりをして終了すると、何も起こりません。
考えてみれば、時間の無駄です。実際に起こらないことをするのはなぜですか？それは非常識です。あなたは単にそれを何もしなかったかもしれません、そしてそれの痕跡がないので違いはなかったでしょう。
ちょっと待って...
2. fakerootの痕跡
couldfakerootの痕跡が残ります。 MortenSickelの回答 のコマンドを見てみましょう。これは非常に優れており、賛成票を投じる価値があります。
$ fakeroot
# echo "Wow I have root access" > root.tst
# ls -l root.tst
-rw-rw-r-- 1 root root 23 Oct 25 12:13 root.tst
# ls -l /root
ls: cannot open directory /root: Permission denied
# exit
$ ls -l root.tst
-rw-rw-r-- 1 ubuntu ubuntu 23 Oct 25 12:13 root.tst
一見すると、fakerootを使用することは時間の浪費でした。結局、fakerootを使用していなければ、同じ結果が得られます。
ここでの微妙なことはこれです：
$ cat root.tst
Wow I have root access
つまり、ファイルのコンテンツはまだルートであることを覚えています。 fakerootを使用しない場合でも同じ結果が得られると言うかもしれません。そうです、この例は単純すぎます。
別の例を見てみましょう：
$ fakeroot
# touch x
# touch y
# chown myuser:myuser x
# ls -l > listing
# exit
$ ls -l
total 4
-rw-rw-r-- 1 myuser myuser 152 Jan 7 21:39 listing
-rw-rw-r-- 1 myuser myuser 0 Jan 7 21:39 x
-rw-rw-r-- 1 myuser myuser 0 Jan 7 21:39 y
$ cat listing
total 0
-rw-rw-r-- 1 root root 0 Jan 7 21:39 listing
-rw-rw-r-- 1 myuser myuser 0 Jan 7 21:39 x
-rw-rw-r-- 1 root root 0 Jan 7 21:39 y
何が起きたのか見てみましょう。まったく効果がないrootのふりをして、xとyを作成しました。 xはmyuserに属するふりをし、yはrootに属するふりをしました。実際には両方ともmyuserに属しています（最後に見ることができるように）が、私はpretendedのようになります。
次に、リストを作成し、想像力をファイルに保存しました。後でファイルを振り返ると、ファイルの所有者が誰なのかを想像できました。繰り返しますが、それらは実際に私が想像した人々によって所有されているのではなく、単にそれを想像しただけです。
3.それで...なぜあなたはそれをもう一度したいのですか？
そのリストを作成するために、本当にrootである必要はありませんでした。リストを作成し、自分の想像力を反映するように編集することもできます。その通りです。そのためにfakerootは必要ありませんでした。実際、fakerootは実際には何も実行しないことを知っているため、これまでにない能力を獲得することはできません。
しかし、そしてこれがfakerootのすべてです。リストの編集は簡単ではありません。システムにインストールできるパッケージの場合と同様に、tared、gziped、xzed、bzip2edまたはファイルをまとめて保持し、ファイルの権限と所有者を記憶するその他の形式。圧縮ファイルを簡単に変更して、ファイルの所有権を編集できますか？あなたのことは知りませんが、どうしようもありません。
すべてが圧縮されたら、圧縮されたファイルを変更し、所有権とアクセス許可をプログラムで編集するツールを構築できますか？はい、できます。したがって、圧縮する前に所有権を偽造することも、後で変更することもできます。 Debianの人々は、前者の方が簡単だと判断しました。
4. Sudoを使用しないのはなぜですか？
まず第一に、ソフトウェアを構築するためにroot権限は必要ありません。また、ソフトウェアを圧縮するためにroot権限は必要ありません。そのため、必要がない場合は、実際にWindowsユーザーでなくてはなりません。しかし皮肉はさておき、あなたはrootパスワードさえ持っていないかもしれません。
さらに、root権限があるとします。そして、ファイルがルートへの読み取りアクセスのみを持っているように見せかけたいとします。つまり、Sudoで実際にファイルの所有者と権限をrootに変更すると、ルートシェルから抜け出し、すべてをパッケージ化しようとします。 rootアクセス権がないため、ファイルを読み取ることができないため、失敗します。したがって、Sudoを圧縮して、ルートとしてパッケージをビルドする必要があります。効果的には、すべてをrootとして実行する必要があります。
これは悪いですTM。
パッケージャーとしては、root権限は必要なく、取得するべきではありません。パッケージをインストールするときに、いくつかのファイル（A）をrootとしてインストールする必要がある場合があり、そこにroot権限が必要です。 fakerootが行うことは、これを可能にすることだけです。これにより、パッケージャはアーカイバのルートが所有するAを一覧表示できるため、パッケージがユーザーによって解凍されると、アーカイバはルート権限を要求し、ルートが所有するAを作成します。
私の知る限り、fakerootは、ファイル操作のためのroot権限を持っているように見える環境でコマンドを実行します。これは、ユーザーがroot権限/所有権を持つファイルを含むアーカイブ（tar、ar、.debなど）を作成できるようにするのに役立ちます。 fakerootがない場合、正しい権限と所有権でアーカイブの構成ファイルを作成し、それらをパックするには、root権限が必要です。または、アーカイバを使用せずにアーカイブを直接構築する必要があります。
fakerootは、ファイル操作ライブラリ関数（chmod（）、stat（）など）を、ユーザーが本当にrootである場合に、実際のライブラリ関数が持つであろう効果をシミュレートする関数に置き換えることで機能します。
概要：
fakeroot [-l|--lib library] [--faked faked-binary] [--] [command]
詳細はこちら： fakeroot
私はそれをパッケージ構築スクリプトに使用しました。スクリプトを実行する人がルートレベルのアクセス権を持っているかどうかはわかりませんでしたが、スクリプトは、たとえば、ルートに属するファイルを含むtarファイルを生成する必要がありました。これを行う最も簡単な方法は、fakerootの下でパッケージ作成スクリプトを実行することでした。これにより、アーカイバはファイルがrootに属していると信じ込ませ、アーカイブ内にそのようにパックしました。このようにして、パッケージが宛先マシン（完全に別のマシン上）に解凍されたとき、ファイルは奇妙なユーザーや存在しないユーザーに属していませんでした。
考えてみれば、これは、組み込みシステムのrootfs、tar.gzアーカイブ、rpmパッケージ、.debパッケージなど、ある種のアーカイブを構築するための唯一の場所でした。
一般的な使用方法の1つは、失敗したバイナリが本当にアクセスしたいファイルを見つけることです。つまり、ハードコードされたパスと不適切な例外処理によって引き起こされたバグを見つけて修正または回避します。
簡単な答え：
suとSudoはrootとしてコマンドを実行します。 fakerootは、部分的なサンドボックス配置以外では、そうしません。
実際にroot権限がなくてもfakerootを使用できます。 suやSudoがある場合、単純なrm -rf /でシステムを破壊できますが、fakerootではせいぜいホームディレクトリを削除するだけです。