Current status of OSTree and its handling RPM scriptlets?

[Zdenek Dohnal]

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?

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.

Thank you in advance!


Zdenek

-- 
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC

[Jonathan Lebon]

Hi Zdenek,

On Mon, Feb 12, 2024 at 4:58 AM Zdenek Dohnal <zdohnal(a)redhat.com&gt; 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!

[Zdenek Dohnal]

Hi Jonathan!

On 2/13/24 16:47, Jonathan Lebon wrote:
> > 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. :) 
Ok, I thought there are
Fedora Linux, Fedora Silverblue and Fedora 
CoreOS (maybe others :) ). Thanks!
>  The common way to make "image-mode friendly" system state
> changes is
>  to e.g. use a systemd service 
Do you have an example of such systemd service? I could see that a shell 
script can be started by systemd unit to do the migration, but that 
would have to be run in %post scriptlet again AFAIK - unless you would 
require machine restart (and the service is run during reboot) or manual 
service start...

tmpfiles.d won't work for me, I have to make changes in /usr/bin :( - 
looks like it designed for temp/volatile files.

>    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(a)lists.fedoraproject.org
>  To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
>  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/[e-mail]...
>  Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue 
-- 
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC

[Stephen Gallagher]

On Thu, Feb 22, 2024 at 4:51 AM Zdenek Dohnal <zdohnal(a)redhat.com&gt; wrote:
>  Hi Jonathan!
>
>  On 2/13/24 16:47, Jonathan Lebon wrote:
>
>  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. :)
>
>  Ok, I thought there are Fedora Linux, Fedora Silverblue and Fedora CoreOS (maybe others
> :) ). Thanks!
>
>  The common way to make "image-mode friendly" system state changes is
>  to e.g. use a systemd service
>
>  Do you have an example of such systemd service? I could see that a shell script can be
> started by systemd unit to do the migration, but that would have to be run in %post
> scriptlet again AFAIK - unless you would require machine restart (and the service is run
> during reboot) or manual service start...
>  
https://docs.fedoraproject.org/en-US/packaging-guidelines/Initial_Service...