Skip to content

Conversation

@AidanDelaney
Copy link
Member

When a container is launched with a UMASK value or the UMASK value is set in a launch environment
then respect that value

Summary

Before we launch a direct or shell process on Unix, set the umask to be whatever octal value is in the UMASK environment variable.

Release notes

When a container is launched with a valid octal string in the UMASK environment variable then that value is used as umask in PID 1.


Related

Resolves #1550


Context

We no-longer support Windows. However, I've factored this PR out into a umask_unix and umask_windows. We may wish to cease this practice.

@AidanDelaney AidanDelaney requested a review from a team as a code owner November 5, 2025 07:35
@AidanDelaney AidanDelaney force-pushed the feature/respect-umask branch 3 times, most recently from d730581 to 317922e Compare November 5, 2025 11:20

// SetUmaskWith the injected function umaskFn
func SetUmaskWith(env Env, umaskFn func(int) int) error {
if umask := env.Get("UMASK"); umask != "" {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there precedence in using UMASK env specifically? Should it be CNB_LAUNCH_UMASK?

We may need to have this updated in the spec for documentation.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've used UMASK as I though of use-cases where someone might use an environment variables style buildpack to set this in the launch environment. In that use-case they would pack build foo --env BPE_UMASK=0002. I also used UMASK as it it common to most Linux distros, and other Unixes (or shells). However, I have no objection to CNB_LAUNCH_UMASK


err := SetUmask(l.Env)
if err != nil {
return errors.Wrap(err, "umask")
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we fail hard or warn and continue? If we think failing is the right choice I believe we need to guard this entire thing around a platform version check.

Copy link
Member Author

Choose a reason for hiding this comment

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

I like the idea of warning and continuing. Will make this modification.

@jabrown85
Copy link
Contributor

I've actually wanted this for the normal CNB lifecycle phases as well during build. We set it manually today, but if we could delegate that to lifecycle - that is one less platform specific behavior to execute ourselves.

AidanDelaney and others added 2 commits November 7, 2025 08:30
When a container is launched with a UMASK value or
the UMASK value is set in a launch environment
then respect that value

Signed-off-by: adelaney21 <[email protected]>
Pass a logger down to the process launcher and log when setting
the umaks is incorrect and continue.

Signed-off-by: adelaney21 <[email protected]>
@AidanDelaney AidanDelaney force-pushed the feature/respect-umask branch from e9bd379 to 93c67dd Compare November 7, 2025 09:05
@jabrown85
Copy link
Contributor

@hone @AidanDelaney do you think this requires a spec change? Or is this an implementation detail of our specific implementation of the spec? 🤔

@AidanDelaney
Copy link
Member Author

I don't feel like we're impacting the spec here. But I can run up a quick RFC if you'd like?

@dzuelke
Copy link

dzuelke commented Nov 10, 2025

If buildpacks/rfcs#321 were a thing, could this then not be a simple buildpack that calls umask followed by exec?

@AidanDelaney
Copy link
Member Author

Yes. I can see that buildpacks/rfcs#321 would allow a umask buildpack to provide a binary that would wrap the current auto-detected command and exec it. I'd happily see this PR merged and then remove it once we have flexible process types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Respect UMASK environment variable

3 participants