### EDIT
## OPTION B: Propose a new dedicated top-level directory standard (FHS) for
operating-system state
Instead of placing the SELinux policy store in `/etc`, define a new standard
top-level directory, `/<name>`, for critical system state that must stay
associated with the operating system installation or deployment. It would be
shared by traditional, atomic and immutable distributions, and by any
distribution that adopts it. The package manager databases and the SELinux
policy store would be the first components to live there.
**Admission criteria.** A component belongs only if it:
1. describes or depends on the installed operating system;
2. must stay consistent with it across snapshots, deployments and rollbacks;
3. is modified by system tools, not by users.
**Proposed hierarchy.**
```
/<name>/ # It could be /sysstate, /osstate, /state, /osdata
├── rpm/ # RPM database (today /usr/lib/sysimage/rpm)
├── dpkg/ # other package managers, only where present
├── pacman/
└── selinux/
└── targeted/
└── active/ # policy store (/var/lib/selinux or /etc/selinux)
├── any other critical component
```
Each distribution ships only the subdirectories it uses. Other components are
added later, one at a time, if they meet the admission criteria.
**Same layout, different semantics.**
* **Traditional systems:** writable, so package managers and SELinux tools
update it in place. It must be covered by whatever snapshot mechanism the
administrator uses.
* **Atomic systems:** read-only in the active deployment. Its contents are
updated as part of a new deployment and roll back with it.
* **Immutable or image-based systems:** part of the image or snapshot, with the
same rollback guarantees.
**Benefits.** One location and one rule for every distribution model, with no
further load on the responsibilities of `/etc`, `/usr` or `/var`, and no
generated state in the configuration tree.
**Trade-offs.**
* It needs agreement on the name and semantics among distributions and upstream
projects, so it cannot realistically land in Fedora 46.
* It requires a multi-release migration, probably with compatibility symlinks
for the old paths.
* It adds a new top-level directory, which has to be justified against the
existing hierarchy.
**Relation to this Change.** Option A (move the SELinux store to
`/etc/selinux`) solves the rollback problem now with locations that already
exist. Option B is a longer-term direction, and Option A does not prevent it.
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
