Not sure if SELinux policy needs to learn about the merge as well. Currently, `sudo semanage fcontext -l | rg bin.*=` shows:
``` /sbin = /usr/sbin /bin = /usr/bin ``` And there are executables in both /usr/bin and /usr/sbin with specific labels, e.g. `sudo semanage fcontext -l | rg bin/.*virt` ``` /usr/bin/imagefactory regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/imgfac\.py regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/nova-compute regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/qemu-ga regular file system_u:object_r:virt_qemu_ga_exec_t:s0 /usr/bin/qemu-pr-helper regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/qemu-storage-daemon regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/vios-proxy-guest regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/vios-proxy-host regular file system_u:object_r:virtd_exec_t:s0 /usr/bin/virt-who regular file system_u:object_r:virtd_exec_t:s0 /usr/sbin/condor_vm-gahp regular file system_u:object_r:virtd_exec_t:s0 /usr/sbin/fence_virtd regular file system_u:object_r:fenced_exec_t:s0 /usr/sbin/libvirt-qmf regular file system_u:object_r:virt_qmf_exec_t:s0 /usr/sbin/libvirtd regular file system_u:object_r:virtd_exec_t:s0 /usr/sbin/virtinterfaced regular file system_u:object_r:virtinterfaced_exec_t:s0 /usr/sbin/virtlockd regular file system_u:object_r:virtlogd_exec_t:s0 /usr/sbin/virtlogd regular file system_u:object_r:virtlogd_exec_t:s0 /usr/sbin/virtlxcd regular file system_u:object_r:virtd_lxc_exec_t:s0 /usr/sbin/virtnetworkd regular file system_u:object_r:virtnetworkd_exec_t:s0 /usr/sbin/virtnodedevd regular file system_u:object_r:virtnodedevd_exec_t:s0 /usr/sbin/virtnwfilterd regular file system_u:object_r:virtnwfilterd_exec_t:s0 /usr/sbin/virtproxyd regular file system_u:object_r:virtproxyd_exec_t:s0 /usr/sbin/virtqemud regular file system_u:object_r:virtqemud_exec_t:s0 /usr/sbin/virtsecretd regular file system_u:object_r:virtsecretd_exec_t:s0 /usr/sbin/virtstoraged regular file system_u:object_r:virtstoraged_exec_t:s0 /usr/sbin/virtvboxd regular file system_u:object_r:virtvboxd_exec_t:s0 /usr/sbin/virtvzd regular file system_u:object_r:virtvzd_exec_t:s0 /usr/sbin/virtxend regular file system_u:object_r:virtxend_exec_t:s0 ``` (should Fedora SELinux policy also drop historical paths for simplicity's sake if/when RPMs don't use them anymore?) On Thu, Apr 11, 2024 at 3:39 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > Hi! > > I'm trying to get > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin implemented. > It was approved for F40, but only a few days before the mass rebuild, > so there wasn't time to do much, so it was retargeted to F41. > We now have some time before the F41 mass rebuild, so I want to push > all the changes required in various packages so that we have time to > work out any kinks before the mass rebuild commences. > > When I started looking at individual packages, I discovered that we > have an old rule that packages are SUPPOSED to use "historical paths" > to list their files. This rule was introduced to make the transition > easier when UsrMove was implemented for F17. For example, mount.nfs > was historically installed as /sbin/mount.nfs, so nfs-utils must use > %files:/sbin/mount.nfs, even though /sbin is a symlink to /usr/sbin, > meaning that the real path after installation is /usr/sbin/mount.nfs. > And packages using a file path dependency on mount.nfs must use > /sbin/mount.nfs too. > > To implement this rule, packages must use %buildroot/sbin during > installation and use literal "/sbin/" in the files section. This idea > made sense at the time, but now it seems overcomplicated and > unecessary. It requires additional work from packagers who create the > packages that provide the files, but also additional work from > packagers that want to refer to those files. In fact, I only found > three packages that implement the rule correctly: nfs-utils, glibc, > and ocfs2-tools. So step 0. is to drop the packaging rule: > https://pagure.io/packaging-committee/pull-request/1355 > > As to the actual sbin merge: > > Currently, we have %_bindir==/usr/bin, %_sbindir==/usr/sbin, > and /sbin->/usr/sbin, /bin->/usr/sbin. > > In the end state, we will have %_bindir==%_sbindir==/usr/bin, > and /bin,/sbin,/usr/sbin -> /usr/bin. This end state is simple: > _any_ path will works for any binary. > > It's the transition, as we rebuild packages with the new definition, > that requires some careful handling. > > After experimenting with a few different ways to handle this, the > following approach seems to work best: > > 1. rpm is patched to provide %_sbindir==/usr/bin. > (This affects what paths packages will list after being rebuilt.) > > 2. filesystem is patched to not contain /usr/sbin in %files, > but instead symlink /usr/sbin -> bin in %pretrans. > > On fresh installations, this will succeed, so the merge is in place. > On upgrades, this will fail, meaning that /usr/sbin remains a dir. > There is also a %posttrans scriptlet to attempt a merge on upgrades, > more about this below. > > In particular, since buildroots are created afresh for each build, > package builds will get merged-sbin. > > 3. We need to handle the case where package foo had /usr/sbin/foo, but > this file will be in /usr/bin/foo after rebuild. After the merge is > done, /usr/sbin/foo and /usr/bin/foo will point to the same > location, no problem, but during the transition, users or scripts > might call /usr/sbin/foo. To make this work, filesystem rpm gets a > scriptlet that will create symlinks from /usr/sbin to /usr/bin, for > any files which were installed by packages in /usr/sbin. (A list > was obtained using repoquery.) > > Initially, I wanted to put those scriptlets in individual packages, > but that turns out to be a lot of duplicate work. Some packages > have multiple subpackages with files (currently) in /usr/sbin, so > we'd end up with a lot of churn. Doing it once in filesystem turns > out to be fairly easy. > > 4. We also need to handle the case where other package bar has > Requires:/usr/sbin/foo. Once foo has been rebuilt, it has only an > automatic provides for /usr/bin/foo. We could adjust bar for the > new path, but then bar would not be installable on old systems. > Instead, a compat virtual Provides:/usr/sbin/foo is added to foo. > We know that either /usr/sbin will be a symlink, or that filesystem > will create the /usr/sbin/foo symlink. > > We need to ensure that the filesystem package that is installed is > actually new enough so that the Provides is not a lie. > filesystem.rpm gets a virtual > Provides:filesystem(unmerged-sbin-symlinks)=1 which is used as > Requires:filesystem(unmerged-sbin-symlinks) by foo. > > (An explicit Provides/Requires allows us to adjust or rescind the > mechanism in the future.) > > 5. After this preparatory work is done, we can rebuild > various packages with updated rpm and filesystem. > > Packages which don't use %_sbindir generally don't care. > Some packages which use %_sbindir need small adjustments. > There are some common failure modes: > > a. 'mv %buildroot/%_bindir/foo %buildroot/%_sbindir/' > b. 'ln -s ../bin/foo %buildroot/%_sbindir/foo' > c. Listing both %_bindir/foo and %_sbindir/foo in %files > d. 'ln -sf ../bin/foo %buildroot/%_sbindir/foo.alt' > e. 'ln -sf ../sbin/foo %buildroot/%_bindir/foo.alt' > > To make builds work both before and after the merge, a-c should be > conditionalized on '%if "%{_sbindir}" != "%{_bindir}"'. > > d-e are fixed by using > 'ln -sf --relative %{buildroot}/%_bindir/foo > %buildroot/%_sbindir/foo.alt' > or > 'ln -sf --relative %{buildroot}/%_sbindir/foo > %buildroot/%_bindir/foo.alt' > > I submitted / will submit a bunch of pull requests for various packages, > but not all, so I'm describing this here so that packagers can use this > as a hint. > > 6. As we rebuild packages in merged buildroots, and those packages are > deployed on user systems, in completely new installations, > /usr/sbin will be created as a symlink. On upgraded installations, > /usr/sbin is a directory and will contain a mix of files and symlinks. > > filesystem.rpm also has a scriptlet to check if /usr/sbin contains > symlinks only, and once that's true, it will nuke /usr/sbin and > replace it by a symlink to /usr/bin. This will finalize the merge > on upgraded systems. > > The plan: > > I. Merge https://pagure.io/packaging-committee/pull-request/1355. > This isn't stricly necessary, but makes things simpler. > > II. I've been doing test rebuilds of packages and filing pull requests > as described in 1–4. above. Those should be merged before the other > things, changes are conditionalized on '"%{_sbindir}"=="%{_bindir}"'. > > Some pull requests have already been merged. If you get a pull > request, please review and/or merge. > > https://src.fedoraproject.org/rpms/rpm/pull-request/56 > https://src.fedoraproject.org/rpms/filesystem/pull-request/11 > > https://src.fedoraproject.org/rpms/chkconfig/pull-request/13 > https://src.fedoraproject.org/rpms/coreutils/pull-request/15 > https://src.fedoraproject.org/rpms/cyrus-sasl/pull-request/11 MERGED > https://src.fedoraproject.org/rpms/dmidecode/pull-request/8 > https://src.fedoraproject.org/rpms/exim/pull-request/16 MERGED > https://src.fedoraproject.org/rpms/exim/pull-request/17 > https://src.fedoraproject.org/rpms/glibc/pull-request/91 > https://src.fedoraproject.org/rpms/kmod/pull-request/12 > https://src.fedoraproject.org/rpms/libcap/pull-request/29 MERGED > https://src.fedoraproject.org/rpms/nfs-utils/pull-request/15 > https://src.fedoraproject.org/rpms/ocfs2-tools/pull-request/2 > https://src.fedoraproject.org/rpms/opensmtpd/pull-request/1 > https://src.fedoraproject.org/rpms/policycoreutils/pull-request/42 > https://src.fedoraproject.org/rpms/procps-ng/pull-request/7 > https://src.fedoraproject.org/rpms/rpcbind/pull-request/4 > https://src.fedoraproject.org/rpms/shadow-utils/pull-request/22 > https://src.fedoraproject.org/rpms/systemd/pull-request/131 > https://src.fedoraproject.org/rpms/util-linux/pull-request/17 > > III. I have two coprs: > https://copr.fedorainfracloud.org/coprs/zbyszek/merged-sbin/builds/ > https://copr.fedorainfracloud.org/coprs/zbyszek/unmerged-sbin/builds/ > > The first one has rpm and filesystem with the changes, so the builds > done there get %{_sbindir}==%{_bindir}. Other packages are > rebuilt with the patches from pull requests. > > The second has old rpm and filesystem, and it serves as a check > that the same srpms as from the first copr still build fine without > the merge. > > It should be possible to install the packages from the first copr > onto a system and either end up with a system with some links and > files in /usr/sbin, or /usr/sbin being a symlink. > > I still need to do more builds in the coprs. If it all turns out to > work as expected, I think we're ready to execute the merge. > > IV. After the pull requests for rpm and filesystem are accepted, > I'll build those in a side tag so that they appear in the > buildroots at the same time. (Things would be even more confusing > with just one of those.) > [rpm, filesystem] > > There is a bunch of packages which do 5c in the list above. > Those will FTI until they have been rebuilt. I'll build those > in the same side tag so that the buildroot is not broken and > we don't get cascading build failures. > [rpcbind, systemd-udev, policycoreutils] > > Once that's done, the side tag can be merged and packages > will see the new buildroot layout as they are rebuilt. > > V. Other packages will need to rebuild to change the layout. > I think it'll make sense to rebuild any packages which have had > patches applied. There is no "flag day", but it'd be great if > we rebuild most packages with files in /usr/sbin, so that we can > actually test if the full transition works as expected. > > VI. A special case of V. is packages using usermode helper with files > in /usr/bin and /usr/sbin. Here, each package is different and > input from maitainers will be needed. > > As long as those packages are not rebuilt, they will continue to > function in the old state, but as point they'll need to be fixed or > retired. > > I looked into setuptool, and AFAICT, the package is absolete and > doesn't actually work. A candidate for retirement. > > I'm sure that I missed some corner cases. In case something breaks, > let me know, I'll try to fix or help to fix. > > I want to finish working on rpm, filesystem, and other packages > soon (hopefully this week), and merge everything about a week later. > > Zbyszek > -- > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
