sudoはどうですか 内部で動作しますか？ suとは異なり、rootパスワードがなくてもrootになることができるのはなぜですか。 ？このプロセスにはどのようなsyscallなどが関係していますか？ Linuxのギャップのあるセキュリティホールではありませんか（たとえば、パッチの多いsudoをコンパイルできなかったのはなぜですか 通常のsudo しましたが、非特権ユーザーのパスワードを要求しませんでした）？
ログインとsuの内部を読みました。 sudoはどのように使用されるのですか？も読みました。しかし、タイトルにもかかわらず、彼らは主にsuの違いを扱っています およびsudo 。
承認された回答：
実行可能ファイルのsudoを見てください ：
$ which sudo
/usr/bin/sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun 3 2011 /usr/bin/sudo
パーミッションビット---s--x--xが含まれていることに気付くでしょう。 。これらは次のように分類できます：
-|--s|--x|--x
- - first dash denotes if a directory or a file ("d" = dir, "-" = file)
--s - only the setuid bit is enabled for user who owns file
--x - only the group execute bit is enabled
--x - only the other execute bit is enabled
したがって、プログラムでsetuidビットが有効になっている場合（SUIDとも呼ばれます）、誰かがこのプログラムを実行すると、ファイルを所有するユーザーの資格情報（別名）で実行されることを意味します。この場合はルート。
例
ユーザーsamlとして次のコマンドを実行した場合：
$ whoami
saml
$ sudo su -
[sudo] password for saml:
sudoの実行に気付くでしょう 実際にはrootとして実行されています：
$ ps -eaf|grep sudo
root 20399 2353 0 05:07 pts/13 00:00:00 sudo su -
setuidメカニズム
SUIDがどのように機能するか知りたい場合は、man setuidをご覧ください。 。これは、私ができるよりもよく説明しているマニュアルページからの抜粋です：
setuid（）は、呼び出しプロセスの実効ユーザーIDを設定します。呼び出し元の
有効なUIDがrootの場合、実際のUIDと保存された
set-user-IDも設定されます。 Linuxでは、setuid（）は、_POSIX_SAVED_IDS機能を備えたPOSIXバージョンのように
実装されます。これにより、
set-user-ID（root以外）プログラムは、そのユーザー特権をすべて削除し、
特権のない作業を行ってから、元の有効なユーザーIDを
再利用できます。安全な方法。ユーザーがrootであるか、プログラムがset-user-ID-rootである場合は、特別な注意が必要です。
setuid（）関数は、呼び出し元の
有効なユーザーIDをチェックし、それがスーパーユーザーである場合、すべてのプロセス関連のユーザーIDは
uidに設定されます。これが発生した後、
プログラムがルート権限を取り戻すことはできません。
ここでの重要な概念は、プログラムには実際のユーザーID（UID）と有効なユーザーID（EUID）があるということです。このビットが有効になっている場合、Setuidは実効ユーザーID（EUID）を設定しています。
関連：Ssh – tcp-keepaliveはsshでどのように機能しますか？
したがって、カーネルの観点から、この例ではsaml は元の所有者（UID）のままですが、実行可能ファイルの所有者がEUIDに設定されています。
setgid
また、sudoコマンドの権限を分類するとき、2番目のビットグループはグループ権限用でした。グループビットには、set group id（別名setgid、SGID）と呼ばれるsetuidに似たものもあります。これは、所有者のクレデンシャルではなくグループのクレデンシャルを使用してプロセスを実行することを除いて、SUIDと同じことを行います。
参考資料
- setuidウィキペディアページ
- setuidのマニュアルページ