Sudo 源代码指南

sudo 源代码树将前端程序、插件实现、可复用库、生成的语言解析器和可移植性支持分开。应从可执行文件的入口开始，然后跟随插件接口；仅按目录名阅读代码树会掩盖策略边界。

前端与命令流程 #

src/sudo.c 是 sudo 前端。 Its early path establishes invocation details, parses command-line options, initializes configuration and logging, and hands authorization and execution decisions to the configured plugins. The front end is deliberately distinct from policy: the policy plugin decides whether a command is allowed, while the I/O plugin can record or mediate execution.

Other entry points include visudo, cvtsudoers, sudoreplay, and testsudoers. Their source lives with shared front-end code rather than in isolated program directories. Identify the executable target in the local Makefile.in before tracing a call, because a file in src/ is not necessarily linked into every binary.

include/sudo_plugin.h defines the boundary between the front end and plugins. The default policy implementation is under plugins/sudoers/; that tree contains sudoers parsing, matching, policy decisions, logging, and associated plugin hooks. I/O logging and replay code are also plugin-oriented concerns. Porting or policy work should begin at these interfaces, not by changing front-end privilege handling.

队列宏 #

include/sudo_queue.h 包含 BSD 风格的侵入式队列宏。 A node embeds an entry link, while a head stores the first element and, for tail queues, a tail reference. The major families differ by linkage and whether the head tracks a tail:

The macros generate no allocation, locking, lifetime management, or type-safe iterator object. Code using a queue must keep embedded elements alive and protect concurrent mutation. Prefer the local header’s macros and semantics over a host <sys/queue.h> because BSD-derived headers have diverged.

库与可移植性 #

lib/ contains reusable components consumed across front ends and plugins, while lib/util/ supplies low-level utility and compatibility routines. The latter includes wrappers, bounded string and path handling, allocation helpers, logging support, reference-counted strings, and fallbacks for interfaces that a target platform lacks. Public declarations in include/ make the reuse boundary visible; the sudo_ prefix often identifies project-owned wrappers:

# define getdelim(_a, _b, _c, _d) sudo_getdelim((_a), (_b), (_c), (_d))

Do not assume every sudo_ function is a simple alias. A wrapper can supply fallback semantics, input validation, or a platform workaround. Trace its declaration and implementation before substituting a native libc call.

Autoconf probes in configure.ac and m4/ select available platform features. That is the portability boundary for headers, functions, privileges, and operating-system behavior; #ifdef branches in a caller are often consequences of those generated configuration results.

生成的解析器与配置数据 #

The sudoers plugin checks in generated outputs so release builds do not require parser generators. Follow source-to-output relationships instead of editing generated files:

The build’s developer or regeneration rules run the configured parser, lexer, and data-generation tools. Regenerate through those rules after changing .y, .l, or .in inputs; otherwise a source checkout can contain inputs and outputs that disagree. Parser symbol prefixes and regeneration prerequisites are build configuration details, so inspect the relevant Makefile.in and configure output rather than invoking a generator with guessed flags.

导航策略 #

For a policy question, begin in plugins/sudoers/ and follow the plugin callbacks declared in include/sudo_plugin.h. For command launch or option handling, begin in the appropriate src/ entry point. For I/O recording, follow the I/O plugin interfaces and sudoreplay reader path. For an operating-system discrepancy, search lib/util/, m4/, configure.ac, and generated configuration headers.

上游 sudo 源代码树及其已提交的构建文件是权威地图，因为生成名称和插件组成会随版本变化。