Nomad v0.7.0-rc3
Windows Server 2016
nomad run example.nomad fails with a permission error.
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.
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:
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!
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/
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.
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).
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
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.
Just encountered this today, based on all the discussion I'm still not 100% clear on what the best course of action is.
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
Most helpful comment
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.