Skip to content
This repository has been archived by the owner on Jul 14, 2021. It is now read-only.

PowerShell Wrappers: Docs assume elevation since Windows cannot access modules directory when non-elevated #472

Open
stuartpreston opened this issue Aug 19, 2015 · 16 comments
Labels
Platform: Windows Type: Bug Doesn't work as expected.

Comments

@stuartpreston
Copy link

ChefDK 0.7.0

When running in a non-elevated PowerShell window, PSModulePath does not contain the path to the modules directory. This is because PSModulePath and Path appear to be set at a SYSTEM level only by the installer.

PS C:\Users\StuartPreston> Import-Module Chef
Import-Module : The specified module 'Chef' was not loaded because no valid module file was found in any module
directory.
At line:1 char:1
+ Import-Module Chef
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (Chef:String) [Import-Module], FileNotFoundException
    + FullyQualifiedErrorId : Modules_ModuleNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand

PS C:\Users\StuartPreston> $env:PSModulePath
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
PS C:\Users\StuartPreston>

The workaround is to set a USER environment variable to %windir%\system32\WindowsPowerShell\v1.0\Modules;%PSModulePath%

Also the usual rules apply about setting the Execution Policy correctly otherwise you run into this:

PS C:\Users\StuartPreston> Import-Module chef
Import-Module : File C:\opscode\chefdk\modules\chef\chef.psm1 cannot be loaded because running scripts is disabled on
this system. For more information, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ Import-Module chef
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [Import-Module], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess,Microsoft.PowerShell.Commands.ImportModuleCommand
PS C:\Users\StuartPreston>

Perhaps the docs/blog posts need to reflect the above. Unless you are running Chef-Client locally on your workstation for scenarios that require admin access, most of the commands do not require elevation in Windows so this could be a common issue.

@stuartpreston
Copy link
Author

cc @smurawski

@smurawski
Copy link

Cc @ksubrama

@adamedx adamedx changed the title PowerShell on Windows cannot access modules directory when non-elevated PowerShell Wrappers: Docs assume elevation since Windows cannot access modules directory when non-elevated Aug 19, 2015
@adamedx
Copy link

adamedx commented Aug 19, 2015

Context seems to be the blog post / other docs on how to install the PowerShell wrappers: https://www.chef.io/blog/2015/08/17/chefdk-0-7-0-released/

@ksubrama
Copy link

Hmm - a system module path should work, even as a user. Was the powershell session restarted after chef-dk was installed?

@stuartpreston
Copy link
Author

Yes it was, the environment variable is visible in a CMD prompt, however it seems PowerShell does its own thing with it - this blog post describes the behavior better than I can: https://www.sapien.com/blog/2012/05/22/psmodulepath-discrepancies/

In fact now I've run PowerShell as an administrator once, I appear to have a PSModulePath that is set whether I am running privileged or not. Need to repro on a clean machine.

@ksubrama
Copy link

@stuartpreston Can you tell us what $PSVersionTable prints in powershell. I now suspect that we're seeing some strange behavior depending on powershell version involved. Also, what version of windows are you running?

@stuartpreston
Copy link
Author

Sure thing, though I would say it's fairly low priority to chase down, I'm running Windows 10 Enterprise (build 10240) in this case.

PS C:\Users\StuartPreston> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.0.10240.16384
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
CLRVersion                     4.0.30319.42000
BuildVersion                   10.0.10240.16384
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3

@ksubrama
Copy link

Thanks for that. We'll keep an eye on it and run some tests on non-admin scenarios across powershell versions to see if there's some behavior change.

@ksubrama
Copy link

ksubrama commented Sep 2, 2015

We identified a possible issue where if a reboot is pending, windows installer wasn't broadcasting updates to PSModulePath until after a reboot (or unless you restarted explorer.exe). I'm not sure how much of what you're seeing is due to that @stuartpreston but it could be one possible issue.

@cjuerg
Copy link

cjuerg commented Oct 16, 2015

Assuming you have installed ChefDK on Windows to C:\opscode using the .msi installer package change shortcut property "Target" to
C:\Windows\system32\cmd.exe /c set PSModulePath=%PSModulePath%;C:\opscode\chefdk\modules\ & echo C:\opscode\chefdk\bin\start-chefdk.ps1 | powershell.exe -noprofile -executionpolicy bypass -command -

@scarolan
Copy link

scarolan commented Nov 4, 2015

Confirmed @cjuerg 's fix works on Windows 10 with ChefDK 0.9.0. I love my new ChefDK Icon!

ksubrama pushed a commit that referenced this issue Jan 11, 2016
Version ChefDK with a static version number
@Learath
Copy link

Learath commented Mar 19, 2016

I get the same error -
Import-Module : File C:\opscode\chefdk\modules\chef\chef.psm1 cannot be loaded because running scripts is disabled on
this system. For more information, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:123

  • ... l | out-string | iex; Import-Module chef -DisableNameChecking;echo 'P ...
  •                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    • CategoryInfo : SecurityError: (:) [Import-Module], PSSecurityException
    • FullyQualifiedErrorId : UnauthorizedAccess,Microsoft.PowerShell.Commands.ImportModuleCommand

cjuerg's fix does not work for me, however running as administrator does fix the message. The executionpolicy is set to restricted FWIW:
PS C:\WINDOWS\system32> Get-executionpolicy
Restricted

@Learath
Copy link

Learath commented Mar 20, 2016

After trying to debug this for a while, I ran across something that is probably a clue, but I can't explain:
If I run the exact command from the link (C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File C:\opscode\chefdk\bin\start-chefdk.ps1) from powershell it works, while if I run the link I get the error above.

@thommay thommay added Type: Bug Doesn't work as expected. and removed Bug labels Feb 1, 2017
@bastianschwarz
Copy link

Hey everyone,

I poked around a bit today and found the following:

The start-chefdk.ps1 spawns a new PowerShell process without the -ExecutionPolicy Bypass parameter so the policy defaults back to restrcted (or whatever you system default policy was set to) and are therefore blocked again.

I just extended the spawn to

start-process powershell.exe -verb runas -argumentlist '-ExecutionPolicy Bypass','-noexit','-command',"$chefdkcommand; (get-host).ui.rawui.windowtitle = '$chefdktitle'"

now with the policy arguments and everything works fine.

So, I guess the script just needs to be adjusted and everything will be fine?

@grv87
Copy link
Contributor

grv87 commented Sep 23, 2017

Is it a problem to sign chef.psm1? Chef MSI files are signed with valid signature, so could be PowerShell modules.

@Chef-Mike
Copy link

Can you just sign chef.psm1?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Platform: Windows Type: Bug Doesn't work as expected.
Development

Successfully merging a pull request may close this issue.