Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

virtiofs: Run unprivileged without feature gate #10657

Merged
merged 1 commit into from Nov 15, 2023

Conversation

germag
Copy link
Contributor

@germag germag commented Oct 31, 2023

What this PR does / why we need it:

Currently, virtiofsd can only run unprivileged for sharing ConfigMaps, Secrets, etc., but to be able to share filesystem PVs requires the feature gate ExperimentalVirtiofsSupport.

This PR removes that restriction, making it possible to share filesystem PVs using unprivileged virtiofsd if the feature gate is disabled, and continue running as root if the feature gate is enabled. So this change doesn't affect users that are already running a privileged virtiofsd.

Running virtiofsd without privileges has some limitations, for instance, virtiofsd cannot switch uids/gids so all the new files created inside the PV will be owned by the same uid/gid (the virtiofsd uid/gid) regardless of the uid/gid of the process that created them inside the VM. After the merge, all the limitations and workarounds will be documented (see kubevirt/user-guide#734).

Signed-off-by: German Maglione gmaglione@redhat.com
Tested-by: Javier Cano Cano jcanocan@redhat.com

Release note:

Exposing Filesystem Persistent Volumes (PVs)  to the VM using unprivilege virtiofsd.

@kubevirt-bot kubevirt-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. size/XL labels Oct 31, 2023
@germag
Copy link
Contributor Author

germag commented Oct 31, 2023

/cc @jcanocan
/cc @alicefr

@germag
Copy link
Contributor Author

germag commented Oct 31, 2023

/ok-to-test

@kubevirt-bot kubevirt-bot added the ok-to-test Indicates a non-member PR verified by an org member that is safe to test. label Oct 31, 2023
pkg/virt-controller/services/virtiofs_test.go Show resolved Hide resolved
pkg/virtiofs/virtiofs.go Outdated Show resolved Hide resolved
tests/virtiofs/datavolume.go Outdated Show resolved Hide resolved
)
})
if !libstorage.HasCDI() {
Skip("Skip DataVolume tests when CDI is not present")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the tests expected to run without CDI at all?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we skip the test if CDI is not present (that check was already in the test before my changes)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, my question was more aimed at whether KubeVirt tests run at all without CDI. IOW can we expected CDI always to be present when the tests run (without the need for another check or skip, not present is expected to result in failure)? IIRC it is present by default in kubevirtci.

Copy link
Contributor Author

@germag germag Nov 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ohh, I don't know really, maybe this was copy-pasted from tests/storage/datavolume.go, that was the original location of this test (btw, the first test in that file checks twice per test if the CDI is present, line 91 and 99).

I can remove the check if is unnecessary

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these tests only intended for this CI or also for someone who does not have/needs CDI?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can only speak for CNV where CDI is present in downstream tests.

}
config, _, kvInformer := testutils.NewFakeClusterConfigUsingKV(kv)

enableFeatureGate := func(featureGate string) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not for this PR, but we should really use a common function for doing this

pkg/virtiofs/virtiofs.go Outdated Show resolved Hide resolved
@alicefr
Copy link
Member

alicefr commented Nov 1, 2023

The change looks good to me
/lgtm
/cc @xpivarc

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Nov 1, 2023
@kubevirt-bot kubevirt-bot removed the lgtm Indicates that a PR is ready to be merged. label Nov 2, 2023
@germag
Copy link
Contributor Author

germag commented Nov 2, 2023

/retest-required

@jcanocan
Copy link
Contributor

jcanocan commented Nov 3, 2023

/retest-required

1 similar comment
@germag
Copy link
Contributor Author

germag commented Nov 3, 2023

/retest-required

@alicefr
Copy link
Member

alicefr commented Nov 10, 2023

IMO, the code looks good
/approve
/hold
Wait for another round of reviews, @0xFelix @xpivarc, does this change look sane to you?

@kubevirt-bot kubevirt-bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 10, 2023
@kubevirt-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alicefr

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubevirt-bot kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 10, 2023
Copy link
Member

@0xFelix 0xFelix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

Looks good to me, leaving hold in place to give @xpivarc a chance to look at it.

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Nov 10, 2023
Copy link
Member

@xpivarc xpivarc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a little bit worried that this will give the wrong impression that you could share any volume. Can we clarify this in the PR description + release note?

pkg/virt-controller/services/virtiofs_test.go Show resolved Hide resolved
tests/virtiofs/datavolume.go Outdated Show resolved Hide resolved
tests/virtiofs/datavolume.go Outdated Show resolved Hide resolved
tests/virtiofs/datavolume.go Outdated Show resolved Hide resolved
tests/virtiofs/datavolume.go Outdated Show resolved Hide resolved
Currently, virtiofsd can only run unprivileged for sharing
ConfigMaps, Secrets, etc., so requiring the feature gate
`ExperimentalVirtiofsSupport` enabled, to be able to share PVs.

Let's remove that restriction, making possible to share PVs using
unprivileged virtiofsd if the feature gate is disabled. This has
some limitations, for instance virtiofsd cannot switch the uid/gid.

Signed-off-by: German Maglione <gmaglione@redhat.com>
@kubevirt-bot kubevirt-bot removed the lgtm Indicates that a PR is ready to be merged. label Nov 10, 2023
@germag
Copy link
Contributor Author

germag commented Nov 10, 2023

I am a little bit worried that this will give the wrong impression that you could share any volume. Can we clarify this in the PR description + release note?

Do you mean block PVs?, if so, is it enough calling them "filesystem PVs"?
could you expand on which ones cannot be shared using virtiofs?

@xpivarc
Copy link
Member

xpivarc commented Nov 10, 2023

I am a little bit worried that this will give the wrong impression that you could share any volume. Can we clarify this in the PR description + release note?

Do you mean block PVs?, if so, is it enough calling them "filesystem PVs"? could you expand on which ones cannot be shared using virtiofs?

Yes, the filesystem PVs sound good. What I am more worried about is the privileges issue, users need to be aware there is a limitation to it.

@germag
Copy link
Contributor Author

germag commented Nov 10, 2023

I am a little bit worried that this will give the wrong impression that you could share any volume. Can we clarify this in the PR description + release note?

Do you mean block PVs?, if so, is it enough calling them "filesystem PVs"? could you expand on which ones cannot be shared using virtiofs?

Yes, the filesystem PVs sound good. What I am more worried about is the privileges issue, users need to be aware there is a limitation to it.

We plan to update the documentation, with all the limitations, as soon this PR is merged

@xpivarc
Copy link
Member

xpivarc commented Nov 10, 2023

I am a little bit worried that this will give the wrong impression that you could share any volume. Can we clarify this in the PR description + release note?

Do you mean block PVs?, if so, is it enough calling them "filesystem PVs"? could you expand on which ones cannot be shared using virtiofs?

Yes, the filesystem PVs sound good. What I am more worried about is the privileges issue, users need to be aware there is a limitation to it.

We plan to update the documentation, with all the limitations, as soon this PR is merged

Would you mind posting placeholder PR?

@germag
Copy link
Contributor Author

germag commented Nov 14, 2023

/retest-required

@jcanocan
Copy link
Contributor

I am a little bit worried that this will give the wrong impression that you could share any volume. Can we clarify this in the PR description + release note?

Do you mean block PVs?, if so, is it enough calling them "filesystem PVs"? could you expand on which ones cannot be shared using virtiofs?

Yes, the filesystem PVs sound good. What I am more worried about is the privileges issue, users need to be aware there is a limitation to it.

We plan to update the documentation, with all the limitations, as soon this PR is merged

Would you mind posting placeholder PR?

Done: kubevirt/user-guide#734

Copy link
Member

@xpivarc xpivarc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/hold cancel

@kubevirt-bot kubevirt-bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 14, 2023
@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Nov 14, 2023
@kubevirt-commenter-bot
Copy link

/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

2 similar comments
@kubevirt-commenter-bot
Copy link

/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

@kubevirt-commenter-bot
Copy link

/retest-required
This bot automatically retries required jobs that failed/flaked on approved PRs.
Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

@kubevirt-bot
Copy link
Contributor

kubevirt-bot commented Nov 15, 2023

@germag: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
pull-kubevirt-check-tests-for-flakes 8573154 link false /test pull-kubevirt-check-tests-for-flakes

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. I understand the commands that are listed here.

@kubevirt-bot kubevirt-bot merged commit d39845c into kubevirt:main Nov 15, 2023
36 of 37 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. lgtm Indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants