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.

Sign up for GitHub

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

Jump to bottom

Analyze fails with kubernetes mounted volumes #271

Closed
matthewmcnew opened this issue Mar 13, 2020 · 2 comments · Fixed by #272
Closed

Analyze fails with kubernetes mounted volumes #271

matthewmcnew opened this issue Mar 13, 2020 · 2 comments · Fixed by #272
Labels
type/bug Something isn't working
Milestone
lifecycle-0.7.1

Comments

@matthewmcnew
Copy link
Contributor

When executing the lifecycle inside a kubernetes pod we specify the pod's securityContext.fsgroup to mount volumes as the CNB_USER. This will be result in the volume mounts for /layers and /cache owned by root with the group specified fsGroup.

The EnsureOwner lifecycle check will still attempt to chown the volume mounts on these volumes because it checks both the uid and gid. This results in an error on analyze:

failed to chown volumes: chown /layers: operation not permitted
@matthewmcnew matthewmcnew added type/bug Something isn't working status/triage labels Mar 13, 2020
@matthewmcnew matthewmcnew changed the title Analyze fails chown layers Analyze fails chown layers on kubernetes mounted volume Mar 13, 2020
@matthewmcnew matthewmcnew changed the title Analyze fails chown layers on kubernetes mounted volume Analyze with kubernetes mounted volumes Mar 13, 2020
@matthewmcnew matthewmcnew changed the title Analyze with kubernetes mounted volumes Analyze fails with kubernetes mounted volumes Mar 13, 2020
@ekcasey
Copy link
Member

ekcasey commented Mar 13, 2020

I think we can assume that, if the gid, is correctly, lifecycle doesn't need to fix the permissions. This shouldn't break the pack case when we need to chown the volumes, but should fix the permissions error you are seeing in k8s.

@ekcasey ekcasey mentioned this issue Mar 13, 2020
Merged
@ekcasey ekcasey added this to the 0.7.1 milestone Mar 13, 2020
@matthewmcnew
Copy link
Contributor Author

After testing #272 on minikube, it seems that not all storage classes will accurately respect the securityContext.fsgroup. Is it possible to just check that those directories are writeable?

@ekcasey ekcasey mentioned this issue Mar 13, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type/bug Something isn't working
Projects
None yet
Milestone
lifecycle-0.7.1
Development

Successfully merging a pull request may close this issue.

play nice with k8s PodSecurityContext fsGroup buildpacks/lifecycle
2 participants
@matthewmcnew @ekcasey