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

nomad run example.nomad requires Admin privileges on Windows #3491

Closed
schmichael opened this issue Nov 2, 2017 · 10 comments · Fixed by #6009
Closed

nomad run example.nomad requires Admin privileges on Windows #3491

schmichael opened this issue Nov 2, 2017 · 10 comments · Fixed by #6009

Comments

@schmichael
Copy link
Member

Nomad version

Nomad v0.7.0-rc3

Operating system and Environment details

Windows Server 2016

Issue

nomad run example.nomad fails with a permission error.

Reproduction steps

In a non-admin powershell:

nomad init
nomad run example.nomad

Error getting job struct: Error getting jobfile from "example.nomad": symlink C:\Users\mschurter\go\src\github.com\hashicorp\nomad\example.nomad C:\Users\MSCHUR~1\AppData
\Local\Temp\2\jobfile712770031: A required privilege is not held by the client.

It appears the way hashicorp/go-getter is used to copy the jobfile into a temporary file doesn't work on Windows.

@ghost
Copy link

ghost commented Jan 20, 2018

For everyone here who has the same issues where they can't plan or run jobs via nomad without specific admin privileges: there is a possible workaround to make this possible.
obviously these changes will weaken the security of your system so please use with caution.
As to why this issue happens is that the creation of symbolic links requires the "SeCreateSymbolicLinkPrivilege" which is only granted to administrators but can me changed via security policy.
To change the policies simply do the following changes:

  1. Launch "secpol.msc" via Start or Run (Windows + R)
  2. Navigate through Security Settings → Local Policies → User Rights Assignment.
  3. Find "Create symbolic links" and add yourself to the User list.

@Justin-DynamicD
Copy link

Justin-DynamicD commented Jan 20, 2018

First off: great discovery, nice to know exactly what function is being performed/blocked.

Academically, I'm curious to the actual risk of allowing symbolic links. It's something done in Linux almost casually and the risk (to me) is minimal if you're not running as admin. I mean I guess someone can link and impersonate a file ... but again: only in the user space so said trojan wouldn't be elevated in anyway.

Worth further investigation, at any rate and a great find!

@Justin-DynamicD
Copy link

Quick google shows that Windows 10 already enables this by default if you enable developer mode ... so it seems times are changing:

https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/

@ghost
Copy link

ghost commented Jan 21, 2018

Great to know but also really strange.
I have Windows 10 in developer mode up and running myself and without the changes for "SeCreateSymbolicLinkPrivilege" it didnt work for me.
Maybe there is some magic going on behind the curtains which didnt apply in my case.
It could be because my current user is in a domain but without further investigation its only a guess.

@Justin-DynamicD
Copy link

article notes it depends on how you call/create said link. Seems you may need to do both (be in developer mode AND have said policy in place).

I'm in a similar boat where my user account is simply a user (not admin) of W10 and I have to provide unique creds for admin access, so my experience has been similar to yours. I'm goign to dig more, however because, as stated, it seems like "legacy thinking" might be the culprit here more than any serious security risk (can't find anything specific on how it would be exploited unless you were an actual admin as well).

@ninoles
Copy link
Contributor

ninoles commented Apr 20, 2018

This is the crazy thing in Windows 10 w/ symlinks:
if you're a standard user, you need the SeCreateSymbolicLinkPrivileges, which is only possible to set if you have Windows Pro. It should also work if you are the built-in Administrator. However, if you're only a user account of type Administrator, the privilege is always dropped and you will be required to answer the elevation privileges prompt. It really sucks.

On scripts I distribute to dev, I end up always using nomad run - so that the copy never happen. I also avoid using go-getter as is for local file copy which is not great. I enter an issue for this in go-getter (hashicorp/go-getter#39). Which, btw, also refer to #1714

@harkamals
Copy link

Think of a global financial institution, which hardens windows os to the extent possible and getting to have exceptions to group policy is near impossible.

But, hey, why would a file copy need to create a symbolic link, this itself asks for a review.

@atrauzzi
Copy link

Just encountered this today, based on all the discussion I'm still not 100% clear on what the best course of action is.

@GenvidCI
Copy link

GenvidCI commented Jun 12, 2019

Windows have an utility called mklink. If you try it using the following command, you'll find that the same error occurs:

mklink link target
Access is denied.

Windows has 3 different ways to link files and folders:

Creating a symbolic link requires a Group Policy access as mentionned before or Developper Mode as describe for the SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag or using fsutil.

mklink [/d] link target

C++ function to create Symlink

Creating a junction link only works on folders but does not require any special privilege.

mklink /j link target

C++ function to create Junction Link

Creating a hard link only works on file on the same volume but does not require any special privilege.

mklink /h link target

C++ function to create Hardlink

schmichael added a commit that referenced this issue Aug 1, 2019
@tgross tgross removed this from the near-term milestone Jan 9, 2020
@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 Nov 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants