Module secctx_compat 

Pure, controller-free reasoning about whether a mover’s resolved security context can read a backup source PVC, and the inverse — whether a future workload can read what a restore mover writes to a target PVC.

Why this is deliberately conservative

A predicate that reasons only from security contexts cannot see file mode bits, and world-readable 0644 data is everywhere. So it can almost never be certain a backup will fail — the only honest verdicts from the spec alone are:

• Compatible — provably fine: the mover is root, or its UID exactly matches every writer’s UID. (We never claim Compatible on a group/fsGroup basis — see below.)
• Unknown — we cannot tell from the spec (the common case). The mover-side readability preflight (in crates/mover) is the layer that certainly validates this at runtime, where the files are actually mounted.
• LikelyIncompatible — reserved for near-certainty (the mover shares neither UID nor any group with the writers). Used only for a best-effort, advisory admission warning; the reconcile loop maps it to a non-blocking Unknown condition (the certain False comes from the mover preflight), so a 0644 tree never produces a false alarm on a successful backup.

fsGroup is excluded from backup-source reasoning

A backup mounts the source PVC read-only by default, so the kubelet never recursively chgrp’s it and fsGroup grants nothing for readability there. We therefore never treat an fsGroup match as a path to Compatible for backups. (fsGroup is only counted toward the mover’s process group set, which can only ever soften a mismatch to Unknown — the safe direction.) On restore the target is a fresh read-write volume where the kubelet does apply fsGroup, so assess_restore_compat treats an fsGroup match as a positive signal — the predicates are intentionally asymmetric.

Source::readOnly: false (#254) exists precisely to re-enable that walk on the source, so it partially unwinds this: with a writable source and an fsGroup, the kubelet MAY chgrp the tree to the mover’s own group, which would make the source readable no matter who wrote it. That is not enough for Compatible — whether the walk happens depends on the CSIDriver’s fsGroupPolicy and on fsGroupChangePolicy, neither of which is in the spec — but it IS enough to invalidate every workload-ownership comparison. So assess_read_compat takes the effective readOnly and short-circuits to Unknown { FsGroupMayApply }. Without that, the one configuration the flag exists to enable would be reported LikelyIncompatible while working fine.

Structs

MoverIdentity

The mover’s effective identity for read reasoning (backup source), built from the resolved, post-invariant container + pod security contexts.

MoverWriteIdentity

The mover’s effective identity for write reasoning (restore target).

WorkloadIdentity

A workload pod’s identity, for comparing against a mover. One per consuming pod.

Enums

CompatBasis

Basis on which a backup mover was found read-compatible. Exhaustive (thesis §5.5).

MoverReadCompat

Whether a backup mover can read the source PVC’s files. See the module docs for why Compatible is rare and LikelyIncompatible rarer still.

RestoreBasis

Basis on which a restore was found write-compatible with the future consumer.

RestoreUnknown

Why a restore write-compatibility verdict is undecidable from the spec alone.

RestoreWriteCompat

Whether a future workload can read what a restore mover writes. The restore counterpart of MoverReadCompat — fsGroup IS load-bearing here (fresh read-write volume).

UnknownReason

Why a backup read-compatibility verdict is undecidable from the spec alone.

Functions

assess_read_compat

Assess whether a backup mover can read the source PVC’s files, given the workload pods mounting it. See the module docs for the conservative posture; the result is deterministic (independent of workloads ordering).

assess_restore_compat

Assess whether the future consumer of a restore target can read what the mover writes. fsGroup IS a positive signal here (fresh read-write volume). future is None when no pod consumes the target yet (the common case → ConsumerAbsent).

container_mounting_claim

The container within pod that mounts claim_name: resolve the pod volume(s) backed by the claim, then find the container whose volumeMounts reference one.

is_managed_by_kopiur

Whether a pod is a kopiur-managed object (carries app.kubernetes.io/managed-by=kopiur). A mover Job’s pod mounts the source PVC too, so consumer-discovery and compatibility reasoning must exclude these — otherwise the mover would be compared against (or inherit from) itself. The single definition, shared by the controller and webhook.

mover_identity

Build the mover’s read identity from its resolved container + pod security contexts.

mover_write_identity

Build the mover’s write identity (restore) from its resolved contexts.

pod_mounts_claim

Does this pod mount claim_name via a persistentVolumeClaim volume? The canonical scanner — the controller’s colocation logic reuses this so the two never drift.

pods_mounting_pvc

Pods (in stable input order) that mount claim_name.

workload_identities

Build WorkloadIdentity for every workload pod mounting claim_name — i.e. those mounting the claim, minus kopiur-managed (mover) pods. The shared core for backup, restore, and webhook compatibility checks (one definition, no per-caller duplication).

workload_identity

Extract a WorkloadIdentity from a live pod: the union of init + main container effective UIDs (pod fallback) as writers, and the file-group candidates.