Hi Zdenek, On Mon, Feb 12, 2024 at 4:58 AM Zdenek Dohnal <zdohnal@xxxxxxxxxx> 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! -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
