containers
RFE: lift root requirements for some bootc commands
Feel free to push back on this, but there are a number of rpm-ostree commands that can be run w/o sudo access. rpm-ostree status is what comes to mind. I believe we have policykit (or something like that!) to enable certain commands from non-privileged users. It would be nice if we could do the same for bootc.
I think we want any user w/ shell access to be able to querry:
$ bootc status
ERROR Status: Querying root privilege: This command requires root privileges
Thoughts?
Yeah, this one is a bit harder as it heavily intersects with https://github.com/containers/bootc/issues/2 which is a big change.
An issue with rpm-ostree in general is I think not all use cases will want to necessarily make the system state accessible to unprivileged users - especially as we're likely to expand what data is there.
My offhand instinct here is the easiest thing would be:
- Add a
bootc-readonly-unprivileged.{path,service}unit that, when enabled, monitors for changes in e.g./ostree(for which we bump the mtime on changes) and basically just doesbootc status --json > /run/bootc/status.jsonthat is world-readable - Teach
bootc statuswhen run unprivileged to just parse that JSON
Obviously whether it's enabled by default would be an important property. I could get behind it being on by default upstream.
I think we want any user w/ shell access to be able to querry:
$ bootc status ERROR Status: Querying root privilege: This command requires root privileges
Yep. This one trips me up every time because it's what I'm used to with rpm-ostree.
An issue with rpm-ostree in general is I think not all use cases will want to necessarily make the system state accessible to unprivileged users - especially as we're likely to expand what data is there.
I kind of liken it to rpm -qa. You can run that unprivileged. If there is data that's in there we don't want shown then can we just leave it out in the unprivileged path? If admins don't want unprivileged access to this data then maybe we could make that part configurable?
I kind of liken it to rpm -qa.
I agree that that being accessible unprivileged by default sets a big precedent, as does rpm-ostree having its status be accessible by default.
Another highly relevant example here is systemd allowing anything to introspect all system units by default. It looks like tools such as systemd-sysext run unprivileged too for querying state. And I guess other basic things like the Linux kernel shows all block devices (including USB etc.) by default.
However...let's take a contrasting case here which is podman and container images; today /var/lib/containers is a mode 0700 directory and while there is a remote API for podman it doesn't distinguish from read-write operations. So AFAIK there's no "list all system images" for podman available today to unprivileged users by default. flatpak has a dbus service for its storage.
Tying these together slightly, bootc now also has its own c/storage instance for LBIs and if you want complete status in the general case we'd probably want a mechanism to get access to those too.
I guess all of this kind of argues that podman and bootc are the odd ones out here and indeed we should enable this by default via something like the service above. I guess it's notable here at the implementation level that most of the things above are just reading files for status (with the notable exception of systemd units which are dbus). On the podman side arguably there should be a podman-ro.socket or so...I think libvirt did something like that.
I guess all of this kind of argues that podman and bootc are the odd ones out here and indeed we should enable this by default via something like the service above.
💯
Another example here of an unprivileged user not being able to see version information is OpenShift and it is super frustrating when trying to report issues as the version is one of the most important pieces of information to report.
- https://issues.redhat.com/browse/OCPBUGS-8783
- https://issues.redhat.com/browse/WRKLDS-1042
Great points! On the rpm-ostree side I always felt like "status" was up there w/ /etc/os-release or /etc/redhat-release in terms of checking what version I'm on. Do we consider this information:
booted: image: image: image: [image name] transport: registry version: [version] timestamp: null imageDigest: sha256:[digest]
"at the same level" as os-release? I tend to put it in that bucket, but I might be the only one.
This isn't meant to counter any previous point, just add a lens that may or may not be useful. Cheers,