coreos-boot-edit: relabel rdcore files #3155
Conversation
The `rdcore bind-boot` command write files to the bootfs but currently doesn't relabel them. Let's just relabel it from this side for now. In the future we could look at having `rdcore` call `setfiles` like Ignition does, or better, make `coreos-relabel` a more public API. This fixes coreos/fedora-coreos-tracker#1770 for new installs. Refrained from adding tests for this. I think instead what we need is once all these relabeling issues are fixed, a test that verifies that *everything* is labeled.
| @@ -44,3 +43,9 @@ fi | |||
| # 4. it adds GRUB bootuuid.cfg dropins so that GRUB selects the boot filesystem | |||
| # by UUID | |||
| rdcore bind-boot /sysroot ${bootmnt} | |||
There was a problem hiding this comment.
is this running before the policy is loaded and that's why the created files don't have labels?
| # relabel files rdcore created; ideally in the future rdcore does this itself | ||
| coreos-relabel /boot/.root_uuid | ||
| if [ -e /sysroot/boot/grub2/bootuuid.cfg ]; then | ||
| coreos-relabel /boot/grub2/bootuuid.cfg | ||
| fi |
There was a problem hiding this comment.
if the files that rdcore created are pretty static and we know the context the files should have I wonder if we should just hardcode it in rdcore. i.e. rather than have rdcore call coreos-relabel or some other command that consults the policy we just set the context directly when creating the files?
There was a problem hiding this comment.
Hmm, in general I don't think it's a good idea to hardcode specific labels.
There was a problem hiding this comment.
I would typically agree, just wondering if in this specific instance (a few files in a known location) if it would be advantageous (i.e. to avoid the layering violations and also the complexity of an alternative more comprehensive solution in rdcore).
There was a problem hiding this comment.
one other option here could be to have the package that delivers rdcore deliver a tmpfiles.d entry to request a relabel.
this assumes that there aren't selinux denials that happen between when this is run and tmpfiles that would invalidate this as an option (maybe it does).
The
rdcore bind-bootcommand write files to the bootfs but currently doesn't relabel them. Let's just relabel it from this side for now. In the future we could look at havingrdcorecallsetfileslike Ignition does, or better, makecoreos-relabela more public API.This fixes coreos/fedora-coreos-tracker#1770 for new installs.
Refrained from adding tests for this. I think instead what we need is once all these relabeling issues are fixed, a test that verifies that everything is labeled.