[JENKINS-60054] Wrong umask? Containers with non-root user don't have permissions to agent durable script folders

Type: Bug
Resolution: Unresolved
Priority: Major
Component/s: kubernetes-plugin
Labels:
None
Environment:
Jenkins: 2.190.2
kubernetes-plugin: 1.21.1
jnlp slave: jenkins/jnlp-slave:3.35-5-alpine

Similar Issues:
Powered by SuggestiMate

Show

This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to /home/jenkins/agent.

When running container with non-root user (of course having fsGroup/supplementalGroups to 1000 to match jnlp slave GUID) getting the following error:

 process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba
 (running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer)

Doing that reveals:

 LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied

I know there's a lot of similar issues being reported recently, but this one is different and not related to the workingDir in jnlp slave. I am using jenkins/jnlp-slave:3.35-5-alpine image and have workingDir correctly defaulting to /home/jenkins/agent.

I've seen mainly two suggested workarounds to the issue - change user/group in the container and use runAsUser in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding runAsUser: 1000 might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.

Just to summarize, expected behaviour would be: as long as

 securityContext:
   fsGroup: 1000
   supplementalGroups:
   - 1000

is set on the pod, using containers with non-root and non-/home/jenkins home should work just fine like they used to.

I found another workaround, which is applying this on jnlp container:

 command:
 - /bin/bash
 args:
 - "-c"
 - "umask 002; jenkins-agent"

But I would imagine it wouldn't be secure? Or is it not?

Dee Kryvenko created issue - 2019-11-05 07:48

Dee Kryvenko made changes - 2019-11-05 07:51

Description

Original: This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to `/home/jenkins/agent`.

When running container with non-root user (of course having `fsGroup`/`supplementalGroups` to `1000` to match jnlp slave GUID) getting the following error:

```
process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba
(running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer)
```

Doing that reveals:

```
LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied
```

I know there's a lot of similar issues being reported recently, but this one is different and not related to the `workingDir` in `jnlp` slave. I am using `jenkins/jnlp-slave:3.35-5-alpine` image and have `workingDir` correctly defaulting to `/home/jenkins/agent`.

I've seen mainly two suggested workarounds to the issue - change user/group in the container and use `runAsUser` in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding `runAsUser: 1000` might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.

Just to summarize, expected behaviour would be: as long as

```
  securityContext:
    fsGroup: 1000
    supplementalGroups:
    - 1000
```

is set on the pod, using containers with non-root and non-/home/jenkins home should work just fine like they used to.

I found another workaround, which is applying this on jnlp container:

```
  command:
  - /bin/bash
  args:
  - "-c"
  - "umask 0002; jenkins-agent"
```

But I would imagine it wouldn't be secure? Or is it not?

New: This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to {{/home/jenkins/agent}}.

When running container with non-root user (of course having {{fsGroup}}/{{supplementalGroups}} to {{1000}} to match jnlp slave GUID) getting the following error:

{{code}}
process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba
(running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer)
{{code}}

Doing that reveals:

{{code}}
LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied
{{code}}

I know there's a lot of similar issues being reported recently, but this one is different and not related to the {{workingDir}} in {{jnlp}} slave. I am using {{jenkins/jnlp-slave:3.35-5-alpine}} image and have {{workingDir}} correctly defaulting to {{/home/jenkins/agent}}.

I've seen mainly two suggested workarounds to the issue - change user/group in the container and use {{runAsUser}} in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding {{runAsUser: 1000}} might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.

Just to summarize, expected behaviour would be: as long as

{{code}}
securityContext:
fsGroup: 1000
supplementalGroups:
- 1000
{{code}}

is set on the pod, using containers with non-root and non-{{/home/jenkins}} home should work just fine like they used to.

I found another workaround, which is applying this on jnlp container:

{{code}}
command:
- /bin/bash
args:
- "-c"
- "umask 0002; jenkins-agent"
{{code}}

But I would imagine it wouldn't be secure? Or is it not?

Dee Kryvenko made changes - 2019-11-05 07:51

Description

Original: This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to {{/home/jenkins/agent}}.

When running container with non-root user (of course having {{fsGroup}}/{{supplementalGroups}} to {{1000}} to match jnlp slave GUID) getting the following error:

{{code}}
process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba
(running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer)
{{code}}

Doing that reveals:

{{code}}
LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied
{{code}}

I know there's a lot of similar issues being reported recently, but this one is different and not related to the {{workingDir}} in {{jnlp}} slave. I am using {{jenkins/jnlp-slave:3.35-5-alpine}} image and have {{workingDir}} correctly defaulting to {{/home/jenkins/agent}}.

I've seen mainly two suggested workarounds to the issue - change user/group in the container and use {{runAsUser}} in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding {{runAsUser: 1000}} might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.

Just to summarize, expected behaviour would be: as long as

{{code}}
securityContext:
fsGroup: 1000
supplementalGroups:
- 1000
{{code}}

is set on the pod, using containers with non-root and non-{{/home/jenkins}} home should work just fine like they used to.

I found another workaround, which is applying this on jnlp container:

{{code}}
command:
- /bin/bash
args:
- "-c"
- "umask 0002; jenkins-agent"
{{code}}

But I would imagine it wouldn't be secure? Or is it not?

New: This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to {{/home/jenkins/agent}}.

When running container with non-root user (of course having {{fsGroup}}/{{supplementalGroups}} to {{1000}} to match jnlp slave GUID) getting the following error:

{code}
process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba
(running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer)
{code}

Doing that reveals:

{code}
LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied
{code}

I know there's a lot of similar issues being reported recently, but this one is different and not related to the {{workingDir}} in {{jnlp}} slave. I am using {{jenkins/jnlp-slave:3.35-5-alpine}} image and have {{workingDir}} correctly defaulting to {{/home/jenkins/agent}}.

I've seen mainly two suggested workarounds to the issue - change user/group in the container and use {{runAsUser}} in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding {{runAsUser: 1000}} might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.

Just to summarize, expected behaviour would be: as long as

{code}
securityContext:
fsGroup: 1000
supplementalGroups:
- 1000
{code}

is set on the pod, using containers with non-root and non-{{/home/jenkins}} home should work just fine like they used to.

I found another workaround, which is applying this on jnlp container:

{code}
command:
- /bin/bash
args:
- "-c"
- "umask 0002; jenkins-agent"
{code}

But I would imagine it wouldn't be secure? Or is it not?

Dee Kryvenko made changes - 2019-11-05 07:58

Description

Original: This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to {{/home/jenkins/agent}}.

When running container with non-root user (of course having {{fsGroup}}/{{supplementalGroups}} to {{1000}} to match jnlp slave GUID) getting the following error:

{code}
process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba
(running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer)
{code}

Doing that reveals:

{code}
LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied
{code}

I know there's a lot of similar issues being reported recently, but this one is different and not related to the {{workingDir}} in {{jnlp}} slave. I am using {{jenkins/jnlp-slave:3.35-5-alpine}} image and have {{workingDir}} correctly defaulting to {{/home/jenkins/agent}}.

I've seen mainly two suggested workarounds to the issue - change user/group in the container and use {{runAsUser}} in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding {{runAsUser: 1000}} might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.

Just to summarize, expected behaviour would be: as long as

{code}
securityContext:
fsGroup: 1000
supplementalGroups:
- 1000
{code}

is set on the pod, using containers with non-root and non-{{/home/jenkins}} home should work just fine like they used to.

I found another workaround, which is applying this on jnlp container:

{code}
command:
- /bin/bash
args:
- "-c"
- "umask 0002; jenkins-agent"
{code}

But I would imagine it wouldn't be secure? Or is it not?

New: This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to {{/home/jenkins/agent}}.

When running container with non-root user (of course having {{fsGroup}}/{{supplementalGroups}} to {{1000}} to match jnlp slave GUID) getting the following error:

{code}
process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba
(running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer)
{code}

Doing that reveals:

{code}
LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied
{code}

I know there's a lot of similar issues being reported recently, but this one is different and not related to the {{workingDir}} in {{jnlp}} slave. I am using {{jenkins/jnlp-slave:3.35-5-alpine}} image and have {{workingDir}} correctly defaulting to {{/home/jenkins/agent}}.

I've seen mainly two suggested workarounds to the issue - change user/group in the container and use {{runAsUser}} in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding {{runAsUser: 1000}} might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.

Just to summarize, expected behaviour would be: as long as

{code}
securityContext:
fsGroup: 1000
supplementalGroups:
- 1000
{code}

is set on the pod, using containers with non-root and non-{{/home/jenkins}} home should work just fine like they used to.

I found another workaround, which is applying this on jnlp container:

{code}
command:
- /bin/bash
args:
- "-c"
- "umask 002; jenkins-agent"
{code}

But I would imagine it wouldn't be secure? Or is it not?

Dee Kryvenko made changes - 2019-11-05 08:00

Description

Original: This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to {{/home/jenkins/agent}}.

When running container with non-root user (of course having {{fsGroup}}/{{supplementalGroups}} to {{1000}} to match jnlp slave GUID) getting the following error:

{code}
process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba
(running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer)
{code}

Doing that reveals:

{code}
LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied
{code}

I know there's a lot of similar issues being reported recently, but this one is different and not related to the {{workingDir}} in {{jnlp}} slave. I am using {{jenkins/jnlp-slave:3.35-5-alpine}} image and have {{workingDir}} correctly defaulting to {{/home/jenkins/agent}}.

I've seen mainly two suggested workarounds to the issue - change user/group in the container and use {{runAsUser}} in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding {{runAsUser: 1000}} might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.

Just to summarize, expected behaviour would be: as long as

{code}
securityContext:
fsGroup: 1000
supplementalGroups:
- 1000
{code}

is set on the pod, using containers with non-root and non-{{/home/jenkins}} home should work just fine like they used to.

I found another workaround, which is applying this on jnlp container:

{code}
command:
- /bin/bash
args:
- "-c"
- "umask 002; jenkins-agent"
{code}

But I would imagine it wouldn't be secure? Or is it not?

New: This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to {{/home/jenkins/agent}}.

When running container with non-root user (of course having {{fsGroup}}/{{supplementalGroups}} to {{1000}} to match jnlp slave GUID) getting the following error:

{code}
process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba
(running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer)
{code}

Doing that reveals:

{code}
LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied
{code}

I know there's a lot of similar issues being reported recently, but this one is different and not related to the {{workingDir}} in {{jnlp}} slave. I am using {{jenkins/jnlp-slave:3.35-5-alpine}} image and have {{workingDir}} correctly defaulting to {{/home/jenkins/agent}}.

I've seen mainly two suggested workarounds to the issue - change user/group in the container and use {{runAsUser}} in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding {{runAsUser: 1000}} might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.

Just to summarize, expected behaviour would be: as long as

{code}
securityContext:
   fsGroup: 1000
   supplementalGroups:
   - 1000
{code}

is set on the pod, using containers with non-root and non-{{/home/jenkins}} home should work just fine like they used to.

I found another workaround, which is applying this on jnlp container:

{code}
command:
- /bin/bash
args:
- "-c"
- "umask 002; jenkins-agent"
{code}

But I would imagine it wouldn't be secure? Or is it not?

Dee Kryvenko made changes - 2024-01-12 01:35

Priority

Original: Minor [ 4 ]

New: Major [ 3 ]

Assignee:: Unassigned

Reporter:: Dee Kryvenko

Votes:: 1 Vote for this issue

Watchers:: 4 Start watching this issue

Created:: 2019-11-05 07:48

Updated:: 2024-01-12 03:07

Jenkins

Details

Description

Attachments

Activity

People

Dates