Powershell: Update-Help -Scope AllUsers should check for administrative privileges up front and provide a meaningful error message

Created on 14 Nov 2018  路  5Comments  路  Source: PowerShell/PowerShell

Update-Help -Scope AllUsers requires running with administrative privileges.

Currently, the command doesn't fail until _after_ content has been downloaded.

Instead, an _up-front_ check should be performed, with an error message clearly stating that elevation / running with sudo is required.

As an aside: The error message you currently get _at the end_ only contains the reason for the problem _on Windows_, and the wording of the message is Windows-specific.

Steps to reproduce

Run the following from a NON-elevated / NON-sudo session:

Update-Help -Scope AllUsers

Expected behavior

Unless run from an elevated console / session started with sudo, an error should occur right away, stating the requirement.
[See @DHowett-MSFT's feedback below] An attempt should be made up front to write to the target directory (irrespective of whether the current process is elevated / running with sudo), and, if that fails, an error should be reported right away, recommending running as admin.

Alternatively, we could consider attempting self-elevation on demand.

Actual behavior

A lengthy download process operation is performed, only to fail at the _end_ due to lack of privileges.

Environment data

PowerShell Core 6.2.0-preview.1 on macOS 10.14.1
PowerShell Core 6.2.0-preview.1 on Ubuntu 16.04.5 LTS
PowerShell Core 6.2.0-preview.1 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.345)
Windows PowerShell v5.1.17134.228 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.345)
Area-Cmdlets-Core Issue-Discussion WG-Interactive-HelpSystem

Most helpful comment

This is definitely a problem that's worth fixing, but I don't believe the correct solution is to "check who's calling". There is a number of valid scenarios that would allow a mere mortal, uid > 0, to Update-Help -Scope AllUsers:

  • The user is in a group (say powershell-admins) that is allowed write access to the powershell directory
  • The user has been granted explicit write access to the help folder
  • The user has installed powershell in their home folder, to which they always have "AllUsers" level access.

The only correct way to check whether a user is allowed to write somewhere is to try to write there.

All 5 comments

Currently we have internally IsElevated()which do the check only on Windows.
Perhaps we could add geteuid() in psl-native https://stackoverflow.com/questions/4159910/check-if-user-is-root-in-c
Related #7343

This is definitely a problem that's worth fixing, but I don't believe the correct solution is to "check who's calling". There is a number of valid scenarios that would allow a mere mortal, uid > 0, to Update-Help -Scope AllUsers:

  • The user is in a group (say powershell-admins) that is allowed write access to the powershell directory
  • The user has been granted explicit write access to the help folder
  • The user has installed powershell in their home folder, to which they always have "AllUsers" level access.

The only correct way to check whether a user is allowed to write somewhere is to try to write there.

Good point, @DHowett-MSFT, though the error message if write access is denied should still contain the please-run-as-admin recommendation.

please-run-as-admin recommendation

As system administrator I can disable access specially for admins and allow for regular users 馃槃

I suggest "Please make sure that you have a write access to the path: ..."

@iSazonov: That will be less helpful in the _typical_ scenario, where the answer is: run as admin. We can combine the two, however: "please run as administrator or ensure that you have write access to /path/to/..."

Was this page helpful?
0 / 5 - 0 ratings