sudo と sudo-rs の違い：Rust 版 sudo は何を変えるのか

Fri, 01 May 2026 19:27:08 +0800

sudo は Linux ユーザーにとって最もなじみ深いコマンドの一つである。通常ユーザーが、許可された範囲で一時的により高い権限でコマンドを実行できるようにする。たとえば、ソフトウェアのインストール、システム設定の変更、サービスの再起動などで使われる。

最近 sudo-rs が注目されているのは、Ubuntu 25.10 が従来の sudo を置き換える形で、Rust 実装の sudo-rs をデフォルトで使い始めるためだ。一般ユーザーから見ると、表面上は引き続き sudo と入力する。本当に変わるのはシステムの内側で、実行される実装が Rust 版 sudo になっている可能性がある。

この話では、自然に二つの疑問が出てくる。

従来の sudo に何か問題があるのか。
sudo-rs は日常利用やサーバー設定に影響するのか。

簡単に言えば、普通のデスクトップユーザーはほとんど心配しなくてよい。ただし、サーバーを管理している、複雑な sudoers ルールを書いたことがある、または特殊な sudo の挙動に依存している場合は、きちんとテストする必要がある。

sudo-rs とは

sudo-rs は Rust で書かれた sudo / su の実装である。完全に別物の新しいコマンドを作ることが目的ではなく、従来の sudo の主要機能を再実装しつつ、Rust のメモリ安全性を利用して一般的なセキュリティリスクを下げることを目指している。

従来の sudo は主に C 言語で書かれており、歴史が長く、機能も非常に充実している。その成熟度は安定性をもたらす一方で、保守上の負担にもなる。多くのコードはかなり古い Unix/Linux の利用場面に由来し、その後、大量の互換ロジック、拡張、境界処理が重ねられてきた。

sudo-rs が再実装を選んだ理由には、次のようなものがある。

Rust によりメモリ安全性の問題を減らす。
より現代的なコード構造で保守難度を下げる。
一部の歴史的機能やリスクのあるデフォルト挙動を削る。
Rust に慣れた新しい貢献者を呼び込む。
将来の権限昇格ツールに、より監査しやすい土台を提供する。

ただし、sudo-rs は従来の sudo と 100% 互換の置き換えではない。現在も開発中であり、一部の従来機能はまだ実装されておらず、別の一部は今後も実装されない可能性がある。

一般ユーザーが感じる変化

一般ユーザーにとって、変化はかなり少ない。

これまで通り次のように使う。

`1`	`sudo apt update`

または：

`1`	`sudo systemctl restart nginx`

Ubuntu 25.10 では、sudo が sudo-rs を指す。ユーザーが入力するコマンドを sudo-rs に変える必要はなく、スクリプト内の一般的な sudo 呼び出しも、コマンド名の変更で即座に壊れるわけではない。

見えやすい変化は、パスワード入力時のフィードバックである。 sudo-rs はデフォルトで、パスワード入力時にアスタリスクを表示する。従来の sudo でも設定により同様の挙動にできるが、多くのディストリビューションでは何も表示しない設定がデフォルトだった。

また、一部のエラーや警告メッセージの文面が変わる可能性がある。たとえば、パスワード誤り、権限不足、設定の非互換などでは、以前とまったく同じ文面ではないことがある。人間のユーザーにとって大きな影響はないが、sudo のエラー出力を解析するスクリプトがある場合は確認が必要だ。

管理者が注意すべき違い

本当に注意が必要なのは、システム管理者と上級ユーザーである。

従来の sudo のエコシステムは大きく、多くのサーバーには複雑な sudoers 設定がある。これらの設定には、コマンド引数のマッチング、環境変数の制御、ログ、メール通知、PAM の挙動、ホストグループごとのポリシーなどが含まれることがある。

sudo-rs には現時点で従来の sudo との違いがある。たとえば、元記事では sudo-rs が従来 sudo の sendmail サポートを含まないことに触れている。過去に sudo 使用通知を sendmail で送っていた環境では、移行時に別の方法を用意する必要がある。

認証面では、sudo-rs は PAM を使う。そのため、リソース制限や umask などの挙動は、sudoers ファイルだけに頼るのではなく、より PAM 側で設定する必要がある。以前 sudoers で多くの細部を扱っていた場合、切り替え前にそのルールが今も有効か確認するべきである。

もう一つ重要なのは、コマンド引数位置でのワイルドカード対応だ。 sudo-rs は sudoers ファイルでありがちな設定ミスを避けるため、コマンド引数位置でのワイルドカードをサポートしない。これはセキュリティ上は良いことだが、既存ルールに影響する可能性がある。

Ubuntu で sudo と sudo-rs はどう扱われるか

Ubuntu 25.10 以降、システムはデフォルトで sudo-rs を使う。ユーザーは引き続き sudo と入力し、その下で Rust 実装が動く。

従来の sudo がすぐ消えるわけではない。 Ubuntu の移行設計では、従来の sudo は sudo-ws という形で残される。どうしても従来実装が必要な場合は sudo-ws を使うか、alternatives の仕組みでデフォルト sudo を切り替えられる。

切り替えコマンドは次のような形になる。

`1`	`sudo update-alternatives --config sudo`

ただし、普通のユーザーが積極的に従来 sudo へ戻すことは勧めにくい。 sudoers をカスタマイズしておらず、特殊な挙動にも依存していないなら、ディストリビューションのデフォルトに従うほうが楽である。

古い Ubuntu バージョンで試したい場合、sudo-rs は Ubuntu 24.04 以降 universe リポジトリから入手できる。他のディストリビューションでもパッケージが提供されている可能性はあるが、コマンド名や統合方法は同じとは限らない。

なぜ sudo-rs は Rust を選ぶのか

sudo は高権限ツールである。この種のツールに脆弱性があると、通常のコマンドよりも深刻な結果につながることがある。歴史的にも、sudo には複数の権限昇格脆弱性が存在した。

Rust の強みはメモリ安全性にある。所有権、借用チェック、型システムにより、ダングリングポインタ、境界外アクセス、use-after-free などの一般的な問題を減らせる。これでプログラムが絶対に安全になるわけではないが、C/C++ プロジェクトでよく見られる一群の脆弱性を減らせる。

sudo のように長くセキュリティ上重要な位置にあるツールでは、より安全な言語で書き直すことには現実的な意味がある。これは単なる「Rust を使いたいから Rust」ではなく、保守と監査のコストを下げようとする試みである。

もちろん、言語がすべてのセキュリティ問題を解決するわけではない。権限チェックロジック、設定解析、PAM 連携、環境変数処理、ログ、ユーザー体験は、今後も慎重な設計と長期的なテストを必要とする。

sudo-rs は唯一の選択肢ではない

sudo エコシステムには、もともと他の代替ツールも存在する。

比較的よく知られているのは doas である。 OpenBSD 由来で、より単純で小さな設定を目指している。 sudo ほど複雑ではない点を好むユーザーもいる。

ほかにも、RootAsRole や systemd の run0 など、Rust や systemd 関連の代替案がある。ただし、これらのツールの目的や適用場面は完全には同じではない。

多くの Linux ディストリビューションでは、sudo は今でもデフォルトの選択肢である。 sudo-rs の意味は、ユーザーの習慣を保ちながら、内部実装をより現代的なコード基盤に置き換えようとしている点にある。

移行前に確認すべきこと

個人のデスクトップユーザーなら、ディストリビューションのデフォルト設定に従えばよい。

サーバーやワークステーションを管理している場合は、次の点を確認したい。

複雑な /etc/sudoers または /etc/sudoers.d/ ルールがあるか。
コマンド引数のワイルドカードを使っているか。
sudo のメール通知に依存しているか。
sudo のエラー出力を解析するスクリプトがあるか。
sudoers で umask、リソース制限、環境変数を制御しているか。
LDAP、PAM、SSSD などの認証連携があるか。
automation やデプロイスクリプトが従来 sudo の挙動を前提にしているか。

まずテスト機で確認できる。

sudo -l

その後、重要な保守コマンドを実行し、権限、環境変数、ログ挙動が期待通りか確認する。

sudo-rs へ自分で切り替えるべきか

ディストリビューションがすでにデフォルトで切り替えているなら、普通のユーザーはそのまま受け入れてよい。サーバーや本番環境では、試したいという理由だけで手動置き換えするのは勧めにくい。

より安全な進め方は次の通り。

テスト環境に sudo-rs をインストールする。
既存の sudoers 設定を項目ごとに検証する。
PAM、ログ、監査、automation スクリプトを確認する。
ロールバック方法を確認する。
ディストリビューションが安定した統合を提供してから移行する。

この種のツールは権限チェーン上にあるため、「いくつかのコマンドが動く」だけで安全とは判断しにくい。本当に確認すべきなのは、境界条件と異常系である。

まとめ

sudo-rs は従来 sudo の Rust 実装であり、より現代的で安全なコード基盤で sudo の中核機能を担うことを目指している。 Ubuntu 25.10 がデフォルトで有効化することは、主要ディストリビューションがこの方向を本格的に進め始めたことを示している。

一般ユーザーにとって、変化は小さい。引き続き sudo と入力するだけで、内部実装が sudo-rs になっている可能性があるだけだ。気づくとしても、パスワード入力時にアスタリスクが表示されることや、エラーメッセージが少し変わることくらいである。

システム管理者にとって、重要なのは互換性だ。複雑な sudoers ルール、sendmail 通知、PAM 連携、引数ワイルドカード、sudo 出力に依存するスクリプトがある場合は、アップグレード前にテストすべきである。

Rust による書き直しは万能薬ではない。それでも sudo のようなセキュリティ上重要なツールでは、メモリ安全性リスクと保守の複雑さを減らす方向として、真剣に検討する価値がある。

参考ソース：

Rust on KnightLiブログ