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:
The generated installed Compose plan correctly runs the application sandbox as
UID 997 and GID 988.
Reproduction
-
Prepare and build a staging deployment as an unprivileged user.
-
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
-
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)
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:
The host account resolves to:
The generated installed Compose plan correctly runs the application sandbox as
UID 997 and GID 988.
Reproduction
Prepare and build a staging deployment as an unprivileged user.
Install it as a system deployment, then update it from the same staging
directory:
Inspect ownership in both the installed target and staging directory.
Observed
The complete installed tree is owned by
65534:65534, including:The source staging deployment remains owned by the invoking user except for:
Before the update, the installed operator content was
arbiter:arbiterand thestaging 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
resolved
arbiter:arbitersystem account.ownership and permissions.
change the declared deployment-file owner.
Add update-path regression coverage for target ownership and an invariant test
that installation leaves all staging metadata unchanged.
Environment
0.7.0.dev1at08d1ee835c/opt/arbiterarbiter:arbiter(997:988)nobody:nogroup(65534:65534)