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

Incorrect permissions on resolv.conf (640 instead of 644) when using specifying dns servers in a group level network stanza #11845

Closed
nvx opened this issue Jan 14, 2022 · 5 comments · Fixed by #11856

Comments

@nvx
Copy link
Contributor

nvx commented Jan 14, 2022

Nomad version

Nomad v1.2.3 (a79efc8)

Operating system and Environment details

Linux amd64

Issue

When specifying job -> group -> network -> dns -> servers option, the resolv.conf is being created with 640 permissions preventing non-root processes from reading it.

Reproduction steps

Create a job with the following group network stanza

network {
  dns {
    servers = ["169.254.127.1"]
  }
}

Run the job and exec into the task (I used a docker task) and ls -l /etc/resolv.conf to observe the permissions
on the Nomad host, the file in the alloc working directory also appears to have the wrong permissions, so I don't think it's an issue with docker doing the bind mount

-rw-r-----    1 root     root            46 Jan 11 02:13 /var/nomad/alloc/818cc9c5-c179-d1be-02f2-09255a798662/task/resolv.conf

Expected Result

The permissions of resolv.conf are normally 644

Actual Result

The permissions of resolv.conf are 640

@nvx nvx added the type/bug label Jan 14, 2022
@nvx
Copy link
Contributor Author

nvx commented Jan 14, 2022

As an aside, it looks like servers can't be templated with node metadata (eg, ${meta.foobar}). Is this intentional? If not I can throw in a feature request for that too.

@tgross
Copy link
Member

tgross commented Jan 14, 2022

Hi @nvx. Yeah that's definitely looks like a bug in the shared drivers code (ref mount.go#L72-L82 where we're not setting the permission at all so it's just using the umask.

As an aside, it looks like servers can't be templated with node metadata (eg, ${meta.foobar}). Is this intentional? If not I can throw in a feature request for that too.

Most of the rest of the network block can't be interpolated with client data because we use it for scheduling (ex. we can't interpolate a static port on a client because we'd need to know the value for the scheduler to determine it's safe to put on that client).

But the dns block defaults to the client so it should be safe to interpolate. That's just an oversight. I'll open a new issue for that so that it doesn't get lost when we fix the bug described here.

@tgross tgross added this to Needs Triage in Nomad - Community Issues Triage via automation Jan 14, 2022
@tgross tgross self-assigned this Jan 14, 2022
@tgross tgross moved this from Needs Triage to In Progress in Nomad - Community Issues Triage Jan 14, 2022
@tgross
Copy link
Member

tgross commented Jan 14, 2022

I've opened #11851 to cover the network.dns.servers interpolation feature request.

@tgross
Copy link
Member

tgross commented Jan 14, 2022

Fixed in #11856

Nomad - Community Issues Triage automation moved this from In Progress to Done Jan 14, 2022
@github-actions
Copy link

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Development

Successfully merging a pull request may close this issue.

2 participants