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

Fix restoring of privileged containers #10635

Merged

Conversation

adrianreber
Copy link
Collaborator

Checkpointed containers started with --privileged fail during restore with:

Error: error creating container storage: ProcessLabel and Mountlabel must either not be specified or both specified

This commit fixes it by not setting the labels when restoring a privileged container.

Fixes #10615

Checkpointed containers started with --privileged fail during restore
with:

 Error: error creating container storage: ProcessLabel and Mountlabel must either not be specified or both specified

This commit fixes it by not setting the labels when restoring a
privileged container.

[NO TESTS NEEDED]

Signed-off-by: Adrian Reber <[email protected]>
@adrianreber adrianreber force-pushed the 2021-06-04-privileged branch from 07fe8b6 to d9a1c34 Compare June 10, 2021 10:18
@mheon
Copy link
Member

mheon commented Jun 10, 2021

@rhatdan PTAL

@rhatdan
Copy link
Member

rhatdan commented Jun 10, 2021

I am not sure if this is the correct. What does the content end up being labeled?

@adrianreber
Copy link
Collaborator Author

Starting a new container with --privileged in my Fedora 34 gives me:

  • process label: unconfined_u:system_r:spc_t:s0
  • mount label: system_u:object_r:container_file_t:s0:c1022,c1023

After restore the container has the same labels and starting another container from scratch also gives me the same labels. So new and restored containers have the same labels using --privileged on my system with this change.

@rhatdan
Copy link
Member

rhatdan commented Jun 11, 2021

LGTM

Copy link
Member

@giuseppe giuseppe left a comment

Choose a reason for hiding this comment

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

/lgtm
/hold

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 11, 2021
@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jun 11, 2021
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jun 11, 2021

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: adrianreber, giuseppe

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 11, 2021
@TomSweeneyRedHat
Copy link
Member

LGTM
/hold cancel

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 12, 2021
@openshift-merge-robot openshift-merge-robot merged commit 328174d into containers:master Jun 12, 2021
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
6 participants