|
14 | 14 | ## - Therefore, it MUST only be used with trusted configuration directories on a |
15 | 15 | ## trusted filesystem. |
16 | 16 | ## - This function is not a parser for untrusted data. |
17 | | -## - For per-user configuration directories, the invoking user's primary group is |
18 | | -## assumed to be a trusted private group containing only that user. |
| 17 | +## - For per-user configuration directories, the invoking process's current |
| 18 | +## effective group is assumed to be trusted for that configuration context. |
| 19 | +## In the common case, this is expected to be the user's private group, but |
| 20 | +## this function intentionally follows the current effective group as reported |
| 21 | +## by `id --group --name`. |
19 | 22 | ## - Symlinked configuration directories and symlinked configuration files are |
20 | 23 | ## allowed by this security model. |
21 | 24 | ## - Ownership, group, and permission checks apply to the resolved target as |
|
29 | 32 | ## Additional checks on resolved symlink targets are defense in depth. They are |
30 | 33 | ## not intended to be canonical supported-directory containment checks after |
31 | 34 | ## resolving all symlinks. |
| 35 | +## - For per-user configuration paths, expected ownership for resolved symlink |
| 36 | +## targets is still derived from the resolved pathname being checked. |
| 37 | +## Therefore, if a per-user configuration symlink resolves to a path outside |
| 38 | +## the literal `$HOME` pathname prefix, the resolved target hierarchy is |
| 39 | +## expected to be owned by `root:root` and may be rejected even if it is |
| 40 | +## user-owned. This stricter behavior is accepted as defense in depth. |
32 | 41 | ## - The caller is trusted to pass the intended configuration directories. |
33 | 42 | ## - "Trusted" in this context means: |
34 | 43 | ## * the directory hierarchy is only writable by the trusted owner or an |
|
38 | 47 | ## permission semantics correctly. |
39 | 48 | ## - Parent directories are checked as defense in depth. |
40 | 49 | ## For per-user paths, directories above `$HOME` are expected to be |
41 | | -## administered by root, while `$HOME` and directories below it are expected to |
42 | | -## be administered by the invoking user and that user's trusted private primary |
43 | | -## group. |
| 50 | +## administered by root, while `$HOME` and directories below it are expected |
| 51 | +## to be administered by the invoking user and the invoking process's current |
| 52 | +## effective group. |
44 | 53 | ## - This function performs pathname-based checks before sourcing files. |
45 | 54 | ## A time-of-check/time-of-use race condition remains possible in principle. |
46 | 55 | ## - Within this security model, that limitation is accepted because exploiting |
|
60 | 69 | ## functions: |
61 | 70 | ## * `source_config_error` sets the caller's local `rc`; |
62 | 71 | ## * `source_config_get_expected_owner_group` reads the caller's local |
63 | | -## `invoking_user` and `invoking_group`. |
| 72 | +## `invoking_user` and `invoking_group` values, where `invoking_group` |
| 73 | +## reflects the current effective group selected by this implementation. |
64 | 74 | ## This is intentional and part of the implementation contract of these helper |
65 | 75 | ## functions. They are not designed as fully self-contained pure functions. |
66 | 76 | ## |
|
74 | 84 | ## 2) Per-user configuration directories, such as ~/... |
75 | 85 | ## - directories and files should be owned by the invoking user |
76 | 86 | ## - files must not be writable by "others" |
77 | | -## - group-writable files are acceptable only when the file group is a |
78 | | -## trusted private group of that same user |
| 87 | +## - group-writable files are acceptable only when the file group matches the |
| 88 | +## invoking process's current effective group |
79 | 89 | ## |
80 | 90 | ## Notes: |
81 | 91 | ## - The ownership / permission checks are defense-in-depth and help catch |
|
0 commit comments