bootc-dev / bootc-dev/bootc

Add support for chowning across upgrades

Open
#1,263 9 comments 0 reactions 0 assignees View on GitHub
area/client area/sysusers-tmpfiles
Dominant language
Rust
Stars
2.3k
Forks
230
Avg merge
3d 12h
Merged PRs (30d)
38

Description

Splitting this out from so many issues; https://github.com/bootc-dev/bootc/issues/673 and https://gitlab.com/fedora/bootc/tracker/-/issues/50 are big ones, but those have a lot of links to many prior discussions.

In this proposal we would add to bootc first class support for automatically resetting file ownership even if uids drift.

Let's take the case of `openvswitch` again. It has `/etc/openvswitch` opened by the `openvswitch` user/group, and `/var/log/openvswitch`.

First, let's now assume that `/var/log/openvswitch` gets hard converted to tmpfiles.d (in the package by default). This is what we want anyways, and scopes the problem down to `/etc`.

## Option A: Forcibly allocating at system instantiation time

If systemd-sysusers is in use, we *know* whether a uid/gid is floating or not. Here, we could have something like `bootc container commit` add an xattr `user.bootc.owner` with a value `:` syntax (where either of these could be empty). The idea behind using xattrs is that even though tar (as used by container runtimes) has support for symbolic usernames, container runtimes don't.

When a deployment is being created in a given stateroot, we basically do:

- write new deployment (including copying `/etc` from current one, with current value of `openvswitch` user). The new deployment's `/etc` would have these xattrs (from the tar stream)
- Run systemd-sysusers in the new deployment root to ensure we pick up new users/groups pre-upgrade
- Walk `/etc` in the new deployment, and chown files using the `/etc/passwd` from the new deployment's password database

This would work pretty well because of how we inherit ostree's multiple copies of `/etc`; we wouldn't be mutating the system live at all.

## Option B:

I was going to type something else here but actually I like the above enough that I think it makes the most sense.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.