install: manually label {/etc/fstab,tmpfile.d/bootc-root-ssh.conf}

[mvo5]

Right now bootc supports an experimental install from a non-selinux host when using the BOOTC_SKIP_SELINUX_HOST_CHECK=1 option.

This is nice and works relatively well. However files written during the install like /etc/fstab or the tmpfiles.dfile in /etc/tmpfile.d/bootc-root-ssh.conf must be labeled too.

This commit adds a (rather crude) manual way to do this.

Closes #362

[openshift-ci]

Hi @mvo5. Thanks for your PR.

I'm waiting for a containers member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jeckersb]

/ok-to-test

[cgwalters]

Thanks, clearly a next step here is to add a CI check that walks the filesystem tree for unlabeled files, should be an easy add. I can look at that.

This said, I find myself thinking we may just need to pull out the big hammer of doing a force relabel of /etc and /var in this case.

[ondrejbudai]

/ok-to-test

[mvo5]

/ok-to-test

[cgwalters]

The prow/kola job failure is unrelated, should be fixed by coreos/coreos-assembler@836f8ac

[mvo5]

The prow/kola job failure is unrelated, should be fixed by coreos/coreos-assembler@836f8ac

Thank you! This should be okay to review now, I am not super familiar with rust so not sure if I overcomplicated things (or otherwise did non-idiomatic stuff) but it seems okay (I am really wondering if there is a simpler way to pass "function pointers", happy to look more into this if it's not a good/idiomatic solution). Or if there is a simple(r) way to mock State, in go I would probably just use an interface Labeler with just lsm_label and use that, may I should create a trait "labeler"? Would that be an idiomatic way to test this?

[edit: thoughts about how to avoid the passing in of the function]

[cgwalters]

Thanks, let's go ahead with this as it is an improvement. There is a more complex approach I have in mind as a followup though.

[cgwalters]

/retest