man: document that stdio file targets are opened before the MAC transition - #43646

Re-reviewed the note in man/systemd.exec.xml. The head moved again since the last round, to e30b25f (one commit, documentation only, authored by benkigeek), and the previous head def2909 - like 0ce4870, 36a54f2, 69bd37f, bf49673, 67cdef5, f009241, 1147c0a, abdb95e, 3ebd2bd and fa9d387 before it - is gone from the checkout, so this head was assessed on its own merits. The recorded base SHA 726e17a is again a moved main tip; the true merge base is 92c9f78, so the effective diff is man/systemd.exec.xml alone at +11/-1 - the hwdb.d/, src/, test/ and meson.build changes visible against the recorded base belong to main and were excluded from review.

This round is different in kind from the previous ten. Maintainer feedback arrived twice - "I am not convinced this is necessary ... adds a lot of noise explaining stuff that is very niche" and, inline, "Of course this is opened before invoking the executable ... Invoking the binary is the boundary between the service manager's code and the executable's code", followed by "please drop this paragraph". The author responded by cutting the note from five paragraphs to two, then removing the second of those as well. Everything the previous ten rounds were filed against - the per-permission SELinux enumeration, init_t, sock_file, add_name, the type-derivation prose, the domain_fd_use parenthetical, the audit/permissive/null-device paragraph and the Reproduced narration - is gone from this head. All 57 previously recorded findings therefore target text that no longer exists and are marked fixed, and all 43 existing bot threads are resolved. Note that the direction of travel is removal: the remaining eleven added lines are themselves under an explicit maintainer request to drop, so the findings below matter only if any version of the note survives.

Seven of the eight launched lenses completed within budget: correctness and memory safety, security and robustness, architecture/API/compatibility, coding style and maintainability, tests and regression coverage, plus the two domain lenses - MAC/SELinux policy semantics and DocBook markup/generated output. One lens is incomplete: resource lifetimes and concurrency exceeded its budget and was stopped, so its results are not included; its subject matter overlaps heavily with the correctness and MAC/SELinux lenses, both of which completed and independently reached the descriptor-inheritance finding below. All three validators completed.

Three findings were confirmed, all against the surviving note at 3520-3526.

Two are must-fix. Item 58 is a plain factual error and the only finding in eleven rounds that is not about SELinux: the sentence distributes file:, append: and truncate: across StandardOutput=, StandardError= and StandardInput=, but StandardInput= has no append: or truncate: value - exec_input_table (execute.c:3149-3157) has only null, tty, tty-force, tty-fail, socket, fd, data and file, and config_parse_exec_input() (load-fragment.c:1136-1202) special-cases only fd: and file: before falling through to exec_input_from_string(). The page's own value list for StandardInput= at 3392-3395 agrees, so the note contradicts the page eleven lines above it, and the cross-reference this same commit adds at 3423-3425 routes StandardInput= readers to the wrong claim. This is a regression introduced by over-correcting the very first round's item 1, which asked for StandardInput= to be covered at all. Item 59 is the defect three lenses reached independently: "The resulting descriptor is then inherited across that transition into the unit's own domain" is unconditional, and inheritance is precisely what SELinux does not guarantee across a domain change - the kernel revalidates each inherited descriptor at credential commit and substitutes the null device on denial, and thereafter revalidates read/write/append against the current subject rather than honouring the opener's authorization. The author established this mechanism himself in rounds 9 and 10; the sentence as written tells an administrator the opposite.

One suggestion. Item 60: the definite "across that transition" presupposes a transition always happens, but a unit with no SELinuxContext= and no entrypoint type_transition keeps the manager's domain, and ExecStart=+... commands skip the MAC block entirely since needs_sandboxing is false (exec-invoke.c:5496), so sym_setexeccon_raw() at 6471 is never reached.

Several candidates were dropped. A framing objection - that the note documents an internal ordering as an interface contract, and that "and hence" is not the real causal chain - went to a validator and was not confirmed: it restates the maintainer's own inline point on a thread he already owns, and the implication is in fact sound because the transition takes effect at execve(). A terminology nit on "the target path" at 3523 diverging from "the file system object" at 3423 was dropped as churn inside a block under a drop request, and as re-opening a thread the author already adopted. An antecedent-ambiguity point on "that transition" was dropped as overlapping the sentence item 59 already asks to rewrite. A portability point - that the note names only SELinuxContext= while SMACK's setup_smack() relabels the running process rather than arming execve(), and that SELinuxContextFromNet= can win over SELinuxContext= at exec-invoke.c:6468 - was dropped as a re-framing of the dismissed item 23 now that the current text carries no remediation at all.

The tests lens re-verified from scratch that no build or test machinery needs updating for this head: it reimplemented tools/make-directive-index.py's extraction rules over base and head and got byte-identical key sets, since the added markup is inline elements inside para bodies and the script harvests option/varname only from varlistentry terms - so unlike the earlier head that added init_t, this one adds no systemd.directives(7) entry. refmeta/refnamediv are untouched so man/rules/meson.build cannot go stale; the new para is mid-listitem in both places so the version-info include remains the last child, and all three settings are in tools/command_ignorelist regardless; no test or fixture keys off this page's prose. The markup lens found nothing and confirmed the page parses cleanly, that the em dash has precedent in this same file, and that the spaced StandardInput= idiom flagged as items 44 and 57 is absent from this head. The style lens confirmed no added line exceeds the max_line_length = 109 that .editorconfig sets for man/*.xml. Per the standing scope call, no test was requested for this documentation-only change.

Suggestions

• 1. The note is scoped to the three StandardOutput= modes, but StandardInput=file: opens its path through the same acquire_path() helper even earlier, so it is subject to the identical pre-transition check; a reader of the StandardInput= docs gets no hint.
• 2. "not the one the service ultimately runs in" is stated as an absolute, yet the two contexts are identical when policy defines no transition and no SELinuxContext= is set, and for ExecStart=+... commands where needs_sandboxing is false so the setexeccon() block is skipped.
• 3. The init_t parenthetical is policy- and instance-dependent: it is the Fedora/RHEL targeted-policy type, the open is actually performed by the posix_spawn()ed pinned systemd-executor child rather than PID 1, and the sentence leaves the per-user manager (a different domain) unanswered.
• 4. "may open it for writing" understates the required policy: append: needs the distinct append permission, open is its own permission, O_CREAT is added for write modes so parent-directory access is needed too, and the target may be an AF_UNIX socket, FIFO or special file with different classes.
• 5. init_t will be pulled into the generated systemd.directives(7) index by tools/make-directive-index.py, listing a distro policy type as a systemd constant; is the established precedent for SELinux type names.

Nits

• 6. "MAC (Mandatory Access Control)" inverts the spell-out-first convention used throughout man/, and describing the transition as "associated with the execution" is wrong for SMACK, which applies the label to the running process rather than at execve().

Must fix

• 7. The permission enumeration never mentions write. acquire_path() adds O_CREAT only for O_WRONLY/O_RDWR, and setup_output() opens file:/truncate:/append: as O_WRONLY (plus O_TRUNC/O_APPEND), so a policy granting only open/append/create still denies file: and truncate:. Conversely StandardInput=file: is opened O_RDONLY and can never create the file, so the create and enclosing-directory advice does not apply to it.

Suggestions

• 8. Nothing on this path calls mac_selinux_create_file_prepare(), so a file the manager creates takes its type from the parent directory's type transition rather than from any fcontext rule for the path; that resulting label is what decides whether the service can then use the file.
• 9. "the checks apply to the corresponding object class instead" is right for FIFOs and device nodes but wrong for AF_UNIX sockets: acquire_path() attempts open() first and only falls back to connect() on ENXIO, so the sock_file checks are additive rather than replaced, and connectto is evaluated against the listening peer's label, not the socket path's.

Must fix

• 10. The shared read-write descriptor happens only when the output mode is file:, not append: or truncate:. setup_input() computes rw solely from std_output/std_error == EXEC_OUTPUT_FILE (exec-invoke.c:426-427), so StandardInput=file:/x with StandardOutput=append:/x opens O_RDONLY, acquire_path() adds no O_CREAT, and setup_output() still dup2()s that read-only fd for all three modes - nothing is created and no create/write/append is exercised.

Suggestions

• 11. Directory access is stated only as a consequence of create, but the manager-side open() resolves the whole path, so search on class dir is needed for every component unconditionally; and "the corresponding access to the enclosing directory" is worth naming as write and add_name alongside create.
• 12. The AF_UNIX case is missing write on sock_file, which the kernel's MAY_WRITE check in unix_find_other() requires, so a StandardInput=file: socket target labelled per this text is still denied; connectto is also a unix_stream_socket permission, and the FIFO/device classes (fifo_file, chr_file/blk_file) are worth spelling out.
• 13. The type-transition sentence presents the rarer case as the rule: absent a matching type_transition, security_compute_sid() gives the new file the enclosing directory's own type. Leading with the systemd-side fact - that no file creation context is applied when opening the target - is both more accurate and less fragile than describing the resulting label.

Must fix

• 14. write on class sock_file is attached to the initial open() rather than to the connect(). For StandardInput=file: the open is O_RDONLY (exec-invoke.c:429), so the failing open is checked against read, contradicting the "read for StandardInput=" enumeration above; and since acquire_path() falls through to the socket path only on exactly ENXIO (285-286), an EACCES there never reaches connect() at all. The write requirement comes from unix_find_other()'s MAY_WRITE check during connect_unix_path() (294) and applies in both directions.

Suggestions

• 15. The consequence is framed as MAC-only, but the same ordering means the DAC side of the open uses the manager's credentials: setup_input()/setup_output() at 5563/5576/5582 precede enforce_user() at 6410 and capability_bounding_set_drop() at 6376, so StandardOutput=truncate: at a root-only path succeeds under User=nobody. (dismissed)
• 16. The open also precedes all namespacing - setup_delegated_namespaces() first runs at 6094 and apply_root_directory() at 6404 - so the path is resolved against the host root and is not subject to RootDirectory=/ProtectSystem=/ReadOnlyPaths=; and acquire_path() passes no O_NOFOLLOW, so symlinks are followed with the manager's privileges. (dismissed)
• 17. The descriptor-sharing contract is now stated twice with different scope. The unconditional sentence at 3496-3499 is the inaccurate one for append:/truncate:, and the accurate statement is buried in the SELinux note where a reader looking up descriptor sharing will not find it; narrow 3496 in place instead. (dismissed)
• 18. Restricting the failure to a not-yet-existing shared path invites the inverse conclusion that the pairing works once the path exists. setup_output() dup2()s the read-only stdin fd for all three modes (637-641), so the service gets a read-only stdout/stderr with no append or truncate semantics. (dismissed)
• 19. The AF_UNIX paragraph omits the peer-credential consequence: the connect happens in the manager's context, so a peer authorizing via SO_PEERCRED sees uid 0 and via SO_PEERSEC the manager's domain, not the unit's User= or SELinuxContext=. (dismissed)
• 20. Roughly 40 lines of MAC/SELinux prose are inserted between the truncate: and socket paragraphs, interrupting the value-by-value enumeration so the option list reads as if it ended at truncate:. The block is cross-cutting and belongs after the enumeration or in the existing Mandatory Access Control refsect1 at line 972. (dismissed)
• 21. The SELinuxContext= cross-reference is one-directional: the SELinuxContext= entry at 977-987 says nothing about stdio targets being opened earlier, though it is the first place an administrator chasing a denial looks. (dismissed)

Nits

• 22. The hedging is asymmetric: init_t is qualified with "typically ... on common policies" but "a different domain for the per-user one" is stated absolutely, though that is equally policy-dependent. (dismissed)
• 23. The lead-in is deliberately backend-neutral but every piece of remediation that follows is SELinux-only, so a SMACK or AppArmor administrator learns the problem exists and nothing about the fix; under SMACK a new file takes the creating process's label, the opposite default from SELinux. (dismissed)
• 24. "see the note on the security context this happens in for StandardOutput= below" inverts the reference form used elsewhere on this page, which puts the target element immediately after the referring phrase. (dismissed)

Suggestions

• 25. The note never mentions StandardError=, although it takes file:/append:/truncate: by reference to StandardOutput= and its targets are opened by the same setup_output() call at the same point, so the enumeration reads as if StandardError=file: were exempt; this page's "(or error output, see below)" convention covers exactly this case.
• 26. The shared-descriptor condition is narrower than the code, which makes the startup-failure claim false for a legal unit: setup_input() sets rw from std_output or std_error being EXEC_OUTPUT_FILE at the same path (exec-invoke.c:426-427) and setup_output()'s dup2() shortcut is not gated on the output mode (637-641), so StandardInput=file:/x with StandardOutput=truncate:/x and StandardError=file:/x creates a missing /x and starts.

Nits

• 27. The block switches vocabulary mid-way: its first paragraph says "the path", then a bare "the target" is introduced six times (3531, 3539, 3541, 3543, 3550, 3557) for the same thing, where the surrounding prose already uses "file system object", "the file" and path.
• 28. In the AF_UNIX sentence the trailing "before it fails" attaches to "the target" rather than to the open attempt, and burying the failure behind two modifiers hides that the open() is expected to fail with ENXIO yet must still be permitted before the connect is attempted.

Suggestions

• 29. The shared read-write descriptor carries neither O_APPEND nor O_TRUNC and setup_output()'s dup2() shortcut bypasses the flags computation, so with StandardInput=file:/x plus a file: output plus StandardError=truncate:/x the truncate: never truncates and a co-located append: never appends - contradicting the unconditional truncate: text at 3505-3510, and sharing a single file offset with stdin.
• 30. The creation paragraph names only the broadest policy grant: create on the directory-derived shared type plus write/add_name on the directory, a label the service's own domain often cannot write to. The narrower alternative - pre-creating the target with its intended label, e.g. via tmpfiles.d, so only open plus write/append on one dedicated type is needed - is worth a sentence, with the caveat that it holds only while the file exists.
• 31. "on its own" is stranded four lines after the verb it qualifies and is ambiguous between "each mode creates the path independently" and "the path is created on its own"; and "co-located" is the only occurrence of that word in man/, where this page already says "the same file path".

Nits

• 32. "the connect then additionally requires" uses connect as a bare noun one clause after introducing it as connect(); the same nominalisation appears at 3535 ("the access the open actually requires"), and these two are the only such uses in man/.

Must fix

• 33. "requires create on the path" names a label the kernel never consults: at creation time the path has no inode, so its file_contexts entry is not consulted and create is checked against the SID the new inode will receive - the type-transition result for the manager's domain and the enclosing directory's type, which is what this paragraph's own closing sentences at 3562-3566 say. The neighbouring write and add_name are attributed correctly to the directory, sharpening the contrast; an allow rule written from this text loads and is never consulted.

Suggestions

• 34. The permission enumeration at 3535-3540 switches keying axis mid-list, keying read to a setting (StandardInput=) but write/append to option values, so "write for file:" read as written also demands write for a lone StandardInput=file:, which is opened O_RDONLY and needs only open plus read. The list also omits that the shared O_RDWR open needs read and write together, and that in the sharing case append is never checked at all because setup_output()'s dup2() shortcut returns before flags |= O_APPEND.
• 35. Descriptor sharing is not gated on the descriptor being read-write: rw at exec-invoke.c:426 requires a plain file: output at the same path, but the dup2() shortcut at 641 fires on std_input == EXEC_INPUT_FILE plus path equality alone, from inside the case that also covers append: and truncate:. So StandardInput=file:/x with StandardOutput=append:/x on an existing /x starts successfully and the service's writes fail with EBADF - neither the shared-offset outcome at 3557-3558 nor the startup failure at 3559-3561.
• 36. The startup failure at 3559-3561 is not a MAC denial and emits no AVC: acquire_path() adds O_CREAT only for O_WRONLY/O_RDWR (278-279), the non-sharing StandardInput=file: open is O_RDONLY (429), and setup_input() runs before both setup_output() calls (5563 vs 5576/5582), so the unit fails with a plain ENOENT before the append:/truncate: open that would have created the file is attempted. Granting create or add_name cannot help there.
• 37. The abbreviated append:/truncate: at 3557 is the only place in the whole man/ tree where these options appear without path; every other occurrence on this page, including three in this same paragraph, spells them out. Rendered, it comes out as bold "append:" with a dangling colon.

Nits

• 38. Line 3572 is 117 columns, over the max_line_length = 109 that .editorconfig sets for [man/*.xml], and is the only added line that overruns - the next longest land exactly on 109 - so the in-place reword to "the connection attempt" was evidently not followed by a re-wrap.

Must fix

• 39. The new "except when the path is shared" clause at 3540-3544 asserts that granting read and write covers the open "regardless of which of these modes triggered the sharing", but setup_input() promotes to O_RDWR only for a plain file: output (exec-invoke.c:426-427 tests EXEC_OUTPUT_FILE alone) while setup_output()'s dup2() shortcut at 639-641 fires for all three modes ahead of the flag computation. With StandardInput=file:/x plus StandardOutput=append:/x there is exactly one open and it is O_RDONLY, so write and append are never checked and the prescribed write grant on init_t is never exercised.
• 40. "can trigger the same creation, or instead share an already-open descriptor" presents as alternatives what the code makes one case: rw == true is simultaneously the only condition under which the StandardInput= open carries O_CREAT and the condition under which setup_output() takes the dup2() shortcut. A StandardInput=file: not paired with a plain file: output opens O_RDONLY, gets no O_CREAT and cannot create anything, so a reader grants add_name/create/directory-write for an impossible case; and the sharing direction is inverted, setup_input() running before both setup_output() calls.

Suggestions

• 41. The creation claim at 3547-3551 is unconditional but fails when a StandardInput=file: shares its path with an append:/truncate: output: rw stays false, the input open is O_RDONLY so acquire_path() adds no O_CREAT, setup_output() only dup2()s it, and startup fails with ENOENT in setup_input() before the output side runs. The hedge that follows only qualifies the StandardInput= side.
• 42. The paragraph enumerates only manager-side permissions and closes on "Labelling the path only for the domain the service transitions into is not sufficient" without saying what the service side needs. SELinux revalidates every read()/write() on the inherited descriptor once the current SID no longer matches the opener's, requiring fd { use } to the manager's domain plus read/write/append on the file's type, so a policy written from this note alone loads and then denies the service's first write.
• 43. Attaching create to "the label the new file receives - not on any label defined for the path itself" implies by contrast that the open/write/append permissions at 3535-3543 do apply to the path's own label. In the creation case they do not: the open-time check runs against the derived label too, so granting the manager's domain open/write on a semanage fcontext type yields rules that never fire.
• 44. At 3554 a literal space separates StandardInput= from file:path, rendering as "StandardInput= file:path"; it is the only same-line spaced occurrence of that idiom in man/, where the established form is unspaced.
• 45. 3547-3562 is a single ~16-line paragraph carrying four independent claims and stating the label-derivation negative twice (3552-3553 and again at 3559-3562), with "see below for how that label is derived" pointing six lines down inside the same , which has no visible target in the rendered page.

Nits

• 46. "see the general note on descriptor sharing above" names a section that does not exist; the only text above is the unlabelled pre-existing sentence at 3496-3499, which uses neither "descriptor" nor "sharing". This page's idiom is a bare "see above".

Must fix

• 47. The new paragraph's opening claim that labelling only for the manager's domain "is not sufficient either" is unconditional, but it holds only where the service actually transitions. sym_setexeccon_raw() (exec-invoke.c:6471) runs only when a SELinux context is set and policy need not define a type transition for the executable, so a unit with no SELinuxContext= and no entrypoint rule keeps the manager's domain; file_permission then short-circuits on the SID recorded at open time, no inherited-descriptor sweep happens, and manager-side labelling alone is entirely sufficient. The paragraph at 3526-3530 already hedges with "may differ".
• 48. "Reproduced directly: ... a second, independently-timestamped append denial then appears" narrates a lab observation instead of stating the rule the preceding sentence already states. Nothing above establishes that the reader is looking at audit output, "as expected"/"then appears" scopes the claim to one policy and enforcement mode, grep -rn Reproduced man/ matches only this line, and as a diagnostic it misleads: a dontaudit rule, AVC caching or audit rate-limiting suppresses the second record while the access is still denied.
• 49. The timing in that same sentence looks wrong for enforcing mode. The descriptor is opened in the process that later execve()s the service and is deliberately left without O_CLOEXEC, so the kernel revalidates it at the transition: selinux_bprm_committing_creds() calls flush_unauthorized_files(), which re-checks each inherited descriptor with file_to_av() (an O_APPEND descriptor maps to append) and on failure substitutes the SELinux null device. The second denial is therefore timestamped at execve() and the service's writes then succeed while the output is silently discarded - the more useful symptom to document - with the per-write denial being what permissive mode shows.

Suggestions

• 50. Listing read, write and append together as all re-checked conflicts with the note's own per-mode mapping at 3539-3540: append replaces write rather than adding to it, since revalidation adds MAY_APPEND for an O_APPEND descriptor and only adds FILE__WRITE when MAY_APPEND is absent. For append: a write is checked as append and never as write, for file:/truncate: only write applies, for StandardInput=file: only read (or read and write when shared).
• 51. The closing parenthetical pins the page to a third-party policy's mutable configuration, and no other page in man/ documents an SELinux boolean or its default. domain_fd_use is a compile-time gen_tunable in upstream refpolicy, exposed as a runtime boolean only on derived distro policies; "between all domains" is really between types carrying the domain attribute; and "between the two domains" hides that the check is directional - the service's domain as source against the manager's domain as the descriptor's SID - so a hand-written rule has even odds of being backwards, loading cleanly and changing nothing.

Nits

• 52. "A fd class use permission" inverts the class-name ordering this same note uses at 3579 ("checked against class sock_file") and renders as two adjacent quoted tokens with no connecting word, and bare fd already denotes the fd: option value on this page at 3440 and 3592.
• 53. open and append are used as bare nouns for the operation, where this page writes open() (3135, 3578) and otherwise reserves in this block for permission names (3535, 3539, 3548, 3563); permissions also do not "succeed", checks and operations do.
• 54. Bare "MAC transition" uses an abbreviation the page never introduces - 3526 and the section title at 972 both spell out "Mandatory Access Control" - and the only other occurrences of "MAC" in man/ mean hardware addresses.

Must fix

• 55. Adopting item 49's mechanism has overshot. "No audit record of any kind is produced, so the loss is invisible to ausearch or audit2allow" is contradicted by the reproduction posted in round 9, which showed a second, independently-timestamped avc: denied { append } scontext=httpd_t tclass=file from the service's own domain; "Reproduced directly: ... leaves the target path empty" cannot have come from that run, which was explicitly permissive, since permissive logs but does not block; and the null-device redirection is presented as unconditional behaviour of this feature although open_null_as() is reachable only from EXEC_INPUT_NULL (362), the maybe_inherit_stdout_from_stdin() fallback (500), EXEC_OUTPUT_NULL (573) and the journal-connect fallback (600), with file:/append:/truncate: failing the unit via EXIT_STDOUT/EXIT_STDERR instead. If the SELinux LSM's execve()-time descriptor replacement is meant, it needs attributing to SELinux, and "the subsequent write succeeds and the unit does not fail" needs scoping to enforcing mode.

Suggestions

• 56. "re-checked once more at the point the service's own domain takes over the already-open descriptor" understates the check: read/write/append are file-class permissions revalidated against the current subject on every subsequent read or write, not once at a handover, and there is no systemd-side handover event, since sym_setexeccon_raw() (exec-invoke.c:6471) only arms the context for the following execve().

Nits

• 57. A newline separates StandardInput= from file:path at 3541-3542, which DocBook collapses to a space, so it renders as "StandardInput= file:path" while the same idiom at 3566 is unspaced - the newline counterpart of item 44, whose same-line instance is fixed in this head.

Must fix

• 58. The note distributes all three option values over all three settings ("for file:path, append:path and truncate:path of StandardOutput=, StandardError= or StandardInput=") at 3520-3523, but StandardInput= accepts neither append: nor truncate:. config_parse_exec_input() (load-fragment.c:1136-1202) special-cases only fd: and file: and otherwise falls through to exec_input_from_string(); exec_input_table (execute.c:3149-3157) has no append/truncate entries, which exist only in exec_output_table (3162-3174). The page's own value list for StandardInput= at 3392-3395 offers file:path alone, so the sentence contradicts it and presents StandardInput=truncate:/x as supported when the parser rejects it - and the new cross-reference at 3423-3425 sends StandardInput= readers straight to it.
• 59. "The resulting descriptor is then inherited across that transition into the unit's own domain" at 3525-3526 is unconditional, and it fails in exactly the case the note exists to warn about. acquire_path() (exec-invoke.c:271) opens without O_CLOEXEC and move_fd(..., cloexec=false) installs it (433, 653), so the fd does survive to fexecve_or_execve(); but on an SELinux domain change the kernel revalidates each inherited descriptor at credential commit via flush_unauthorized_files() - fd { use } towards the opener's SID plus the file permission implied by the open mode - and on denial in enforcing mode substitutes the SELinux null device or closes it. Even where inheritance succeeds, read/write/append are revalidated against the current subject on later operations rather than cached from the opener, which is what the author's own two-denial reproduction shows.

Suggestions

• 60. "before SELinuxContext= or any policy-defined transition takes effect" plus the definite "across that transition" at 3525-3526 presupposes a transition always occurs. Two common configurations have none: no SELinuxContext= with no entrypoint type_transition, so the manager's domain is kept; and ExecStart=+.../!! commands carrying EXEC_COMMAND_FULLY_PRIVILEGED, where needs_sandboxing is false (exec-invoke.c:5496) so the MAC block at 6460 and sym_setexeccon_raw() at 6471 are skipped entirely. In both the opening and running subjects are the same domain.

Workflow run

Force-pushed an update addressing the review. The note now also covers StandardInput=file:, so the commit subject and PR title were widened accordingly.

• StandardInput=file: opens its path through the same acquire_path() helper (call site at line 429, ahead of the setup_output() one at 649), so it is subject to the identical pre-transition check and is now named explicitly in the note.
• Dropped the absolute claim that the two contexts differ; it now reads "unless the two are the same".
• init_t is no longer stated as a universal fact: it is now "typically init_t under the targeted policy for the system service manager", with the per-user service manager called out as a different domain.
• Spelled out what the policy actually has to allow: open, append in the append: case, and create — the latter also requiring access to the enclosing directory, since acquire_path() adds O_CREAT for write modes — plus a note that a FIFO, special file or AF_UNIX socket target is checked against the corresponding object class.
• <constant>init_t</constant> → <literal>: tools/make-directive-index.py collects every <constant> element into systemd.directives(7), and a distribution policy type does not belong in that index.
• Reworded "MAC domain transition associated with the execution" to "before the MAC context of the process is adjusted for the service", which also holds for SMACK, where setup_smack() applies the label to the process itself rather than at execve().

One point I did not take: the suggestion that the two contexts are identical for ExecStart=+… because needs_sandboxing is false and the setexeccon() block is skipped. Skipping that block only drops an explicit SELinuxContext= override — an automatic type_transition in policy still applies at execve() for such commands. The wording is therefore generic rather than calling out + as an exception.

Pushed again (3ebd2bd) after going through the inline comments one by one; each thread has a reply with what changed and, where a claim was checkable, the measurement it rests on. Beyond the previous round:

• StandardInput=file: now carries a one-sentence cross-reference to the note, so that section is no longer a dead end for a reader hitting the same denial.
• The note states that SELinuxContext= does not help, verified on a unit that sets it: the denials are unchanged and still recorded against the manager's context.
• The note is split in two paragraphs — mechanism first, SELinux consequences second — and the required access is enumerated (read for StandardInput=, append rather than write for append:, create plus enclosing-directory access for a missing target), with a closing sentence for FIFO/special-file/AF_UNIX targets.
• <literal>init_t</literal>, instance-neutral manager wording, and the SMACK-safe phrasing "before the Mandatory Access Control label of the service process is applied".

One suggestion was not taken — that the contexts also coincide for ExecStart=+… — with the reasoning and the measurement in that thread: skipping sym_setexeccon_raw() drops only the explicit override, while the kernel still applies the automatic type_transition at execve(), so a + command does not stay in the manager's domain.

Pushed abdb95e, which addresses 7–9. Thanks for catching 7 — that was a real regression introduced by my own rewrite, not a pre-existing gap.

7. Correct: setup_output() opens all three modes O_WRONLY (plus O_TRUNC/O_APPEND), so write was missing from the enumeration and a policy following the old wording would still have denied file: and truncate:. Reproduced against an existing httpd_sys_content_t target:

avc: denied { write } comm="(probe.sh)" name="existing.log" tclass=file
     scontext=system_u:system_r:init_t:s0 tcontext=…:httpd_sys_content_t:s0

The enumeration now reads: open in all cases, read for StandardInput=, write for file: and truncate:, and append instead of write for append:.

One half of that finding is too absolute, though: StandardInput=file: is not always O_RDONLY. setup_input() computes rw from whether std_output/std_error is EXEC_OUTPUT_FILE at the same path and then opens O_RDWR (line 429), which does pick up O_CREAT in acquire_path(). A unit with StandardInput=file:X and StandardOutput=file:X where X does not exist creates it:

avc: denied { read write open } name="/…/shared.log" tclass=file  scontext=…:init_t:s0
avc: denied { create }          name="shared.log"    tclass=file  scontext=…:init_t:s0
# afterwards: -rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 shared.log

So the creation paragraph is scoped to "the three StandardOutput= modes, and to StandardInput= only if standard input and output refer to the same path" rather than excluding StandardInput= outright. This is the same case your first-round comment noted in passing.

8. Confirmed and adopted. The same run shows it directly: matchpathcon reports <<none>> for the created path, yet the file came out as httpd_sys_content_t — inherited from the enclosing directory's type transition. The note now says the new file is labelled by the directory's type transition rather than by any file context defined for the path itself.

9. Confirmed and adopted. The open() attempt is checked against sock_file before it fails with ENXIO:

avc: denied { write } comm="(probe.sh)" name="listen.sock" tclass=sock_file
     scontext=system_u:system_r:init_t:s0 tcontext=…:httpd_sys_content_t:s0

The text no longer says "instead": FIFOs and special files are checked against the corresponding class, while for an AF_UNIX socket the checks are cumulative — the sock_file open first, then connectto against the domain of the listening peer.

All measurements on CentOS Stream 10, systemd 257-33.el10, selinux-policy-targeted 42.1.27-2, permissive so that every check is logged rather than short-circuiting at the first denial.

Pushed 1147c0a. #10 was another regression from my own round-3 rewrite — thank you for catching it, same class of mistake as #7.

10. Confirmed in code and reproduced. setup_input()'s rw is true only when context->std_output == EXEC_OUTPUT_FILE (exec-invoke.c:426-427) — it does not check EXEC_OUTPUT_FILE_APPEND/EXEC_OUTPUT_FILE_TRUNCATE. setup_output()'s dup2(STDIN_FILENO, fileno) guard, however, fires for all three output modes whenever std_input == EXEC_INPUT_FILE and the paths match — so pairing StandardInput=file: with append:/truncate: at a not-yet-existing shared path does not fall back to opening its own fd; it duplicates the read-only one setup_input() already opened, and there's nothing to create. Reproduced on both:

$ systemctl start mp-appshared.service    # StandardInput=file:/…/x  StandardOutput=append:/…/x, x absent
(probe.sh): Failed to set up standard input: No such file or directory
mp-appshared.service: Failed at step STDIN spawning …: No such file or directory
Main process exited, code=exited, status=208/STDIN

$ systemctl start mp-truncshared.service  # same with truncate:, identical result
Result=exit-code, ExecMainStatus=208, target not created

So the paragraph now says the shared-descriptor path only exists for file:/file:, and names the append:/truncate: combination explicitly as "does not create it, and the unit instead fails at startup" rather than silently omitting it.

12. Adopted — I had the empirical evidence for this from the previous round already (denied { write } … tclass=sock_file when opening the labelled AF_UNIX target) but hadn't named the permission in the prose. It now reads "checked against write on class sock_file".

11 and 13 I'm leaving as-is, and want to say why rather than silently drop them:

• 11 is correct that search on every directory component is needed for path resolution in general — but that is true of every path-based systemd.exec(5) setting (WorkingDirectory=, ReadWritePaths=, the sandboxing options, …), not something specific to this note, and the page doesn't currently spell out directory-traversal SELinux semantics anywhere else either. Scoping it to just this paragraph would make it look like a StandardOutput=-specific requirement when it isn't one.
• 13 reads as accurate to me as currently worded: "labelled according to the type transition of the enclosing directory" already covers the no-matching-rule case, since security_compute_sid() falling back to the directory's own type is itself the (degenerate) type-transition computation, not a separate mechanism. I don't think the suggested reordering changes what's asserted, so I'd rather not touch a sentence that's already been rewritten twice in this thread for a phrasing preference with no behavioural difference behind it.

Same test environment as before: CentOS Stream 10, systemd 257-33.el10, selinux-policy-targeted 42.1.27-2, permissive.

Pushed 35cb6c1. Fixed 42 and 44; declined 39, 40, 41, 43, 45, 46 — replies in their own threads below.

42 was worth the extra round — it's a different dimension from the sharing/creation gaps in 26/29/33/35/36 (which were about whether the manager's open() succeeds), while 42 is about what happens after: the service's own domain, post-transition, gets independently re-checked on every read/write of the inherited descriptor. Reproduced live on this exact test system:

avc: denied { append } ... scontext=init_t:s0     tcontext=httpd_sys_content_t:s0 tclass=file  [manager, at open]
avc: denied { append } ... scontext=httpd_t:s0    tcontext=httpd_sys_content_t:s0 tclass=file  [service, on its own first write]

Two separate, independently-timestamped denials for the same fd, against two different domains — confirming an admin who follows only the manager-side permission advice in this note would still see the service's own first write denied. Added a new paragraph stating this, with the reproduction. One correction to your framing: fd/use between the two domains is real but gated by the domain_fd_use boolean, which is on by default on the reference (targeted) policy — so it's rarely the actual blocker in practice, and the note says so rather than telling readers to grant it as if it were.

39–41, 43, 45, 46 declined — all accurate, but all in the same sharing/creation area that's now had five rounds of tightening (26 → 29 → 33/35/36 → this round), each fix producing a new gap. The note has said since 36a54f2 that this area's exact conditions are corner cases it does not attempt to enumerate; these findings fall inside that acknowledged boundary. Stopping here on this sub-topic specifically, regardless of what a further round finds on it — happy to pick any of it up in the follow-up already mentioned for the broader "what happens before/around the service's own context" material.

Pushed def2909, correcting the paragraph added for 42 in bf49673 (and left unquestioned through 44's fix in 36a54f2). It was wrong, and worth flagging myself rather than waiting for a round to catch it.

The original text claimed the service-domain re-check produces "a second, independently-timestamped append denial" when the manager-side permissions are granted but the service's own domain lacks them. That was based on a flawed reproduction: forcing SELinuxContext= onto a plain /bin/sh with no valid entrypoint for that domain, which under permissive mode let the transition "fake" through and logged a denial that doesn't reflect real enforcing-mode behavior.

Redone properly — a copy of /bin/sh relabelled httpd_exec_t (an entrypoint httpd_t genuinely has, confirmed via sesearch -A -s httpd_t -c file -p entrypoint), run under a brief real setenforce 1 window, output target labelled so the manager succeeds but the service's domain does not:

• The unit reports Finished / Deactivated successfully — no error, no failed exit code.
• The target file is left completely empty.
• ausearch -m avc for the entire run window returns zero records — not a permissive-style logged-but-tolerated denial, nothing at all.

So the actual behavior: the re-check at the domain transition doesn't deny and doesn't log — it silently substitutes the null device for the descriptor, the write succeeds from the process's point of view, and the output is gone with no audit trail. That's a materially different (and more consequential) claim than what shipped in the previous two commits, so I'm not leaving it standing on a "close enough" basis.

New text avoids naming a specific kernel function, since that part is inferred from observed behavior, not read from this kernel's source — everything else in the paragraph is exactly what was reproduced above. Also dropped the domain_fd_use/fd-class-use parenthetical from the previous version: it was reasoning about the wrong mechanism (a permission-check race), and I have no verified basis for whether it applies to this null-substitution path specifically, so it's gone rather than carried forward on a guess.

I am sorry, but I am not convinced this is necessary. This adds a lot of noise explaining stuff that is very niche (i.e. selinux...) and should really be obvious anyway.

Understood, and I think the version that was here when you looked at it earned that reaction — it had grown to 5 dense paragraphs over a lot of automated review rounds, most of them explaining exactly the kind of thing you're right to call obvious (which SELinux permission the manager's domain needs, for which of the three modes, in which combination).

Pushed e9ecfcb, cutting all of that. What's left is 2 short paragraphs, and the only thing they exist to say is: because the manager opens the path before the unit's own domain exists, an admin can get the manager's side of the labelling right and still have the service's first write silently discarded — no denial, no audit record, unit exits 0, target file just stays empty. That's the one part I don't think is "should be obvious anyway" even to someone who knows the exec-boundary story well, since it's a kernel behavior (null-device substitution at the domain transition) rather than a consequence of systemd's own design. If that one paragraph still isn't worth it, I'd rather hear that directly than keep iterating on wording.

so, i still think this is kinda obvious, but ok. seems ok to merge like this.