Re: Current status of OSTree and its handling RPM scriptlets?
Hi Zdenek,
On Mon, Feb 12, 2024 at 4:58 AM Zdenek Dohnal <zdohnal(a)redhat.com> wrote:
Hi all,
there was an issue (either due a bug or due design) in the past about
RPM OSTree treating %post scriptlets in SPEC file differently than on
Fedora Linux - IIUC the explanation was %post scriptlets were applied on
the server side of the system with RPM OSTree, thus any configuration
changes like switching symlinks with alternatives were not
applied/usable for normal user.
Has it got fixed during the time? Or is there a new technology which
would do the trick for Silverblue and Fedora Linux alike?
Just a note: I would say "for Silverblue and traditional systems
alike" instead. Silverblue is part of Fedora Linux. :)
Because there is a user which was used to setting NOEXEC on
/usr/bin/vi
to prevent running shell from vi as a root when using 'sudo vi' - since
the /usr/bin/vi is shell script now and uses exec to spawn the correct
binary, NOEXEC flags breaks 'sudo vi' completely.
The only possible solution here I see is to use alternatives in %post
scriptlet, but if the situation is the same, the functionality brought
by alternatives (automatic switch from vi -> vim and back if
vim-enhanced is installed without shell restart) won't work in OSTree.
So the high-level situation of scriptlets wanting to modify /var
content is still problematic. And in fact, we'd like to propose a
package change at some point to discourage this (see
https://github.com/coreos/fedora-coreos-tracker/issues/1067).
The common way to make "image-mode friendly" system state changes is
to e.g. use a systemd service or a tmpfiles.d dropin or to bake the
migration into the application itself (all these would of course work
across OSTree and non-OSTree based variants).
Specifically for alternatives, see also
https://github.com/fedora-sysv/chkconfig/issues/9 which calls for
changing how it's implemented to be more compatible with image-based
updates.
Specifically for your issue though, it's not clear to me how much it's
worth supporting this. Do they also have a way to prevent `sudo vi`
from e.g. creating/modifying a systemd unit that can run arbitrary code?
Thank you in advance!
Hope that helps!