Skip to content

System install update corrupts deployment and staging ownership #78

Description

@omry

Summary

Updating a Linux system-scope deployment changed the installed deployment owner
from the blueprint-declared system account to nobody:nogroup (65534:65534).
The same install also changed the source staging state file ownership.

Configuration

The blueprint declares:

environment:
  install:
    system:
      account:
        user: arbiter
        group: arbiter
        on_missing: create

The host account resolves to:

arbiter uid=997 gid=988

The generated installed Compose plan correctly runs the application sandbox as
UID 997 and GID 988.

Reproduction

  1. Prepare and build a staging deployment as an unprivileged user.

  2. Install it as a system deployment, then update it from the same staging
    directory:

    sudo reploy install \
      --dir reploy-staging \
      --scope system \
      --to /opt/arbiter \
      --service arbiter
    
  3. Inspect ownership in both the installed target and staging directory.

Observed

The complete installed tree is owned by 65534:65534, including:

/opt/arbiter
/opt/arbiter/appctl
/opt/arbiter/.reploy
/opt/arbiter/.reploy/state.json
/opt/arbiter/.env
/opt/arbiter/.arbiter.env
/opt/arbiter/conf
/opt/arbiter/data

The source staging deployment remains owned by the invoking user except for:

reploy-staging/.reploy/state.json  65534:65534

Before the update, the installed operator content was arbiter:arbiter and the
staging state was owned by the staging operator.

The service still starts because the installed Compose plan uses the intended
numeric application identity, but host ownership no longer matches the declared
system account or Reploy system-install ownership model.

Expected

  • Installed deployment files and preserved operator content remain owned by the
    resolved arbiter:arbiter system account.
  • The source staging deployment is not mutated by installation, including file
    ownership and permissions.
  • Systemd and Docker lifecycle authority may remain root-managed; that must not
    change the declared deployment-file owner.
  • Installation should verify final ownership before reporting success.

Add update-path regression coverage for target ownership and an invariant test
that installation leaves all staging metadata unchanged.

Environment

  • Reploy: 0.7.0.dev1 at 08d1ee835c
  • Linux system-scope install
  • Target: /opt/arbiter
  • Declared owner: arbiter:arbiter (997:988)
  • Observed owner: nobody:nogroup (65534:65534)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions