Yocto File Ownership QA: Find Host UID Leakage in Installed Artifacts

A recipe's files look owned by the developer in a normal host directory listing. Is that a packaging defect? Not necessarily: Yocto uses Pseudo to represent target ownership while the build runs without real root privileges. The important evidence is the ownership seen in the packaging context and encoded in the resulting package.

Conversely, copying a source tree with ownership-preserving options can import a host user's numeric identity into that target view. The host-user-contaminated check helps catch this mistake during Yocto embedded Linux development, but it is not a complete account-policy audit.

What the warning actually tests

The Yocto Project 5.0.12 insane class reference defines the check: it looks for packaged files outside /home whose user or group ID matches the user running BitBake. A match usually indicates installation with unintended ownership because host and target identities are independent.

Capture the reported package, path, UID, and GID. Determine the intended target owner for that file. A configuration file owned by root and a writable state directory owned by a service account have different requirements; neither should inherit ownership merely because the source was checked out by a particular developer.

The test's scope matters. No warning does not prove every file has the right owner, and a numerical match needs investigation rather than an automatic assumption about the target account's meaning. Check the account policy and the installation command together.

Trace the copy operation into the install task

The do_install reference specifically warns that recursive copying can preserve original UID/GID values. It recommends install, or copying and archive extraction options that do not preserve the source ownership.

Inspect the effective installation function and its task log, including helper scripts called by an upstream make install. Look for archive-style copies, explicit ownership preservation, and extracted tar headers carrying host IDs. A clean top-level recipe can still delegate the problematic operation to a nested script.

For an ordinary configuration file, a recipe-level operation such as install -m 0644 source.conf ${D}${sysconfdir}/example.conf makes the copy intent clear, after creating the destination directory. This is an illustrative pattern; use the actual source and target filename. For a directory tree, review whether cp --no-preserve=ownership or tar --no-same-owner fits the install procedure and other required metadata.

Do not fix the symptom with a blanket recursive ownership change across unrelated files. That can erase intentionally assigned service ownership. Correct the copying rule at the narrowest useful scope, then explicitly apply the target ownership the package requires.

Inspect through the correct ownership view

The Fakeroot and Pseudo explanation describes how Pseudo intercepts operations and records simulated ownership in a persistent database. A normal host ls -l outside that environment does not expose the same view as the fakeroot task.

Use the package format's listing or inspection tool to read the ownership encoded in the built archive. Inspect the specific entry numerically as well as by name, because host account-name resolution can make identical numeric IDs look more meaningful than they are. Avoid treating a host extraction without preserved metadata as a faithful package inspection.

If a custom task modifies the same staged files as a fakeroot task, it must also use the appropriate fakeroot environment and dependency described by Yocto. Moving that mutation to an arbitrary shell step can bypass the ownership model even if the shell command appears to succeed. Never run the whole build as real root to conceal this mismatch.

Confirm the fix without changing the intended target owner

Rebuild the affected installation and package output, rerun QA, and inspect the same archive entry. Check both user and group IDs. For a service-owned directory, verify its intended account mapping and write permissions in the image as a separate functional check.

A useful regression test repeats packaging under a different unprivileged host identity while keeping recipe inputs equivalent. The target ownership should follow the recipe's policy, not the developer's UID. Keep that test focused on ownership; it does not imply that every byte of the package is otherwise reproducible.