Notify user when binary invocation requires permission elevation.

[RokeJulianLockhart]

1. Summary of the new feature / enhancement

   Currently, PowerShell does not notify the user that invoking a binary in $PATH which requires higher permissions (usually those of the superuser) than the invoking user possesses are necessary. It should.

2. Proposed technical implementation details (optional)

   As Does not operate in PowerShell. openSUSE/cnf#8 (comment) describes.

[237dmitry]

Could you show an example of a utility that does not notify about the need to elevate rights?

[RokeJulianLockhart]

#20907 (comment)

@237dmitry, I think you've asked the wrong question for what you want to know, because the answer to what you ask would be PowerShell. I expect you instead want to know what package when installed would allow this behaviour to be reproduced. In that instance, as the aforecited openSUSE/cnf#8 (comment) states, install https://download.opensuse.org/repositories/hardware/openSUSE_Tumbleweed/x86_64/lshw-B.02.19.2+git.20231115-75.3.x86_64.rpm on cpe:/o:opensuse:tumbleweed:20231209.

[237dmitry]

I think you've asked the wrong question

[RokeJulianLockhart]

#20907 (comment)

@237dmitry,

1. RokeJulianLockhart@s1e8h4:~> sudo snap remove powershell-preview && snap install powershell --channel=latest/stable --classic
   snap "powershell-preview" is not installed
   powershell 7.4.0 from Microsoft PowerShell✓ installed
   RokeJulianLockhart@s1e8h4:~> snap list
   Name        Version   Rev    Tracking       Publisher              Notes
   core20      20230801  2015   latest/stable  canonical✓             base
   powershell  7.4.0     261    latest/stable  microsoft-powershell✓  classic
   

2. RokeJulianLockhart@s1e8h4:~> powershell
   PowerShell 7.4.0
   PS /home/RokeJulianLockhart> $PSVersionTable.PSVersion.ToString()
   7.4.0
   PS /home/RokeJulianLockhart> lshw
   lshw: The term 'lshw' is not recognized as a name of a cmdlet, function, script file, or executable program.
   Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
   PS /home/RokeJulianLockhart>
   

[237dmitry]

PowerShell-Snap

I used PowerShell snap (6.*) on NixOS just because then I had no another variant. The impressions were not the best, the functionality was limited, only half of the cmdlets...

> $PSVersionTable.Add('Kernel',$(uname -r))
> $PSVersionTable.Add('PSHome',$PSHome)    
> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.4.0
PSEdition                      Core
GitCommitId                    7.4.0
Kernel                         6.6.6-arch1-1
OS                             ArcoLinux
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSHome                         /opt/pwsh
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

> whereis lshw                             
lshw: /usr/bin/lshw /usr/share/lshw /usr/share/man/man1/lshw.1.gz

>  lshw | sls 'WARNING'
WARNING: you should run this program as super-user.
WARNING: output may be incomplete or inaccurate, you should run this program as super-user.

[RokeJulianLockhart]

#20907 (comment)

@237dmitry, so this could be an example of different behaviour in Windows and Linux? Or do you mean that this might be a distribution-specific issue? Necessarily, can you confirm that what #20907 (comment) depicts is indeed installed-by-default PowerShell functionality, not functional cnf or whereis being automatically invoked, nor a 3rd-party module?

[237dmitry]

Or do you mean that this might be a distribution-specific issue?

Yes, the distribution of PowerShell, I always install pwsh manually from a tarball on releases page.

can you confirm that what #20907 depicts is indeed installed-by-default PowerShell functionality, not functional cnf or whereis being automatically invoked, nor a 3rd-party module?

No, this is the functionality of the utilities themselves, the output is exactly like in bash

[rhubarb-geek-nz]

Going back to the original ticket, "lshw" is in /usr/sbin. Normally only root has /usr/sbin on their PATH.

Non-root users don't have /usr/sbin on their PATH because they are not supposed to run those programs.

That should really be the end of the story.

[237dmitry]

Normally only root has /usr/sbin on their PATH.

/usr/sbin is a relative symlink to /usr/bin. At least in Arch-based distributions.

> $env:PATH.Split(':')
/opt/pwsh
/home/me/bin
/opt/bin
/usr/local/sbin
/usr/local/bin
/usr/bin
/usr/bin/site_perl
/usr/bin/vendor_perl
/usr/bin/core_perl

> gi /usr/sbin

    Directory: /usr

UnixMode     Num   UID   GID      LastWriteTime    Size Name
--------     ---   ---   ---      -------------    ---- ----
lrwxrwxrwx   755     0     0   18.09.2023 16:18         sbin -> bin

[RokeJulianLockhart]

#20907 (comment)

@rhubarb-geek-nz, that's why the shell should notify the user that they need to use elevated permissions to access it. That's the point of this ticket. Other shells and utilities do so.

[rhubarb-geek-nz]

Normally only root has /usr/sbin on their PATH.

/usr/sbin is a relative symlink to /usr/bin. At least in Arch-based distributions.

As I said, normally.

Debian.

$ ls -ld /bin /sbin /usr/bin /usr/sbin
drwxr-xr-x 2 root root  4096 Nov  8 20:26 /bin
drwxr-xr-x 2 root root  4096 May 30  2023 /sbin
drwxr-xr-x 2 root root 36864 Dec 11 04:12 /usr/bin
drwxr-xr-x 2 root root 12288 Dec 11 04:11 /usr/sbin

Ubuntu

$ ls -ld /bin /sbin /usr/bin /usr/sbin
lrwxrwxrwx 1 root root     7 Aug  9  2022 /bin -> usr/bin
lrwxrwxrwx 1 root root     8 Aug  9  2022 /sbin -> usr/sbin
drwxr-xr-x 2 root root 49152 Dec 11 14:16 /usr/bin
drwxr-xr-x 2 root root 20480 Dec 11 14:16 /usr/sbin

RedHat

$ ls -ld /bin /sbin /usr/bin /usr/sbin
lrwxrwxrwx 1 root root     7 Jun 21  2021 /bin -> usr/bin
lrwxrwxrwx 1 root root     8 Jun 21  2021 /sbin -> usr/sbin
dr-xr-xr-x 1 root root 20480 Dec 12 14:49 /usr/bin
dr-xr-xr-x 1 root root  4096 Nov 20 15:25 /usr/sbin

that's why the shell should notify the user that they need to use elevated permissions to access it.

If they are all in a single bin directory, then how do you know?

[RokeJulianLockhart]

#20907 (comment)

Or do you mean that this might be a distribution-specific issue?

Yes, the distribution of PowerShell, I always install pwsh manually from a tarball on releases page.

@237dmitry, have you evaluated snap install powershell --channel=latest/stable && snap run powershell too? Otherwise, this is apples to oranges are far as reproduction is concerned.

Can you confirm that what #20907 depicts is indeed installed-by-default PowerShell functionality?

No, this is the functionality of the utilities themselves, the output is exactly like in bash

That doesn't clarify it.

[RokeJulianLockhart]

#20907 (comment)

If they are all in a single bin directory, then how do you know?

@rhubarb-geek-nz, how do I know what?

[rhubarb-geek-nz]

If they are all in a single bin directory, then how do you know?

@rhubarb-geek-nz, how do I know what?

That you need elevated permission to run it. If you are expecting the shell to do something special, what is it making that determination on? For example it could simply be that the group and other execute permissions are not set. But as we saw with lshw a non root user was able to run it, so it must have executable set for non-root users.

[237dmitry]

have you evaluated snap install powershell --channel=latest/stable && snap run powershell

The first thing I did after installing Linux was uninstall snap and flatpak.

[RokeJulianLockhart]

#20907 (comment)

Likewise, @237dmitry, but in this case, in order for us to have reliable results, using it will be necessary unless we create a separate issue about environment differences. So Snap is more reliable for this.

[237dmitry]

As I said, normally.

Normally, this is when everything works and the latest software is available.

[RokeJulianLockhart]

#20907 (comment)

@rhubarb-geek-nz, I can only suggest https://github.com/openSUSE/cnf.git as an example, although the message it creates hints that it uses the location of the binary:

Absolute path to 'lshw' is '/usr/sbin/lshw', so running it may require superuser privileges (eg. root).

GitHub

GitHub - openSUSE/cnf

Contribute to openSUSE/cnf development by creating an account on GitHub.

[rhubarb-geek-nz]

Standard file systems exist for a reason, it keeps things consistent and simple.

Filesystem_Hierarchy_Standard

If you want sbin and bin all to point to the same directory then live with the consequences.

If you want to run as a non-root user with /usr/sbin on you path, then likewise, that is your own non standard configuration

If the system can't run a command because you mistyped it, it should not start searching everywhere for that program, it should simply say program not found. If you want to look for it, then use the tools to look for it.

C:\>foobar
'foobar' is not recognized as an internal or external command,
operable program or batch file.

or

$ foobar
foobar: command not found

Simple, clear and to the point.

[RokeJulianLockhart]

#20907 (comment)

I don't see how any of that relates to this issue. I don't propose anything which would be impacted by the HFS - permission management is performed per-file, and directory identification doesn't require any modification to the directory polled. Additionally, how I decide or not to invoke a command after it has been identified by the shell is also irrelevant - why would that impact this? The sole scope of this issue is to identify that a command not in $PATH is unable to be invoked due to its permissions, as cnf does.

[rhubarb-geek-nz]

The sole scope of this issue is to identify that a command not in $PATH is unable to be invoked due to its permissions, as cnf does.

If it is not on the PATH then it is not an eligible command to run. The permissions it has are irrelevant because it is in a directory that is not on the PATH. The shell should not be inventing things and looking in directories that are not on the PATH.

-- unless the fully qualified path to the executable was used. The shell should only look on the path when there is no / or \ in the program name.

[RokeJulianLockhart]

#20907 (comment)

@rhubarb-geek-nz, if you're an authority on this, then I'll close the issue as unplanned, but is there any PowerShell policy determining such, or is that merely your own opinion? I see no reason why this shouldn't be desirable, especially since PowerShell is the default shell on Windows, and thus the shell most newbies are familiar with, regardless of OS.

[rhubarb-geek-nz]

• Certainly my opinion
• PowerShell Core is not the default shell on Windows
• Windows already has the application manifest entry regarding elevated permissions required to run the program. See UAC

[mklement0]

Let me try to untangle the various issues:

• The linked openSUSE utility, cnf, is a command-not-found helper, i.e. a tool for interactive convenience that guides users toward resolving an unsuccessful command invocation, such as suggesting package manager-based installation commands for known programs that happen not to be installed, or, as in the case at hand, to point them to a utility that is by default only in the path when running as superuser (via sudo).

  • In other words: In your case, invocation by name only fails for a regular user, but the command-not-found helper recognizes that the name is that of a utility in a directory that is in the superuser's path, and alerts the user to that fact.

  • This has nothing to do with examining the actual target executable for whether it requires running as superuser / with elevation or not, and it is up to each executable to enforce that (as @rhubarb-geek-nz notes, on Windows applications can be manifested to automatically ask for elevation).

  • On at least some Linux distros, Bash comes with a command-not-found-helper that provides package manager-based installation hints by default; on Ubuntu, it uses the built-in /usr/lib/command-not-found utility, which PowerShell's experimental features discussed below now also rely on.

  • To make cnf work in PowerShell, it must be hooked up to $ExecutionContext.InvokeCommand.CommandNotFoundAction, as shown in Does not operate in PowerShell. openSUSE/cnf#8 (comment)

• Historically, PowerShell had only a limited, hard-coded command-not-found helper:

  • When trying to invoke a command that isn't present in the path, but one by that name is present in the current location, a suggestion to invoke the latter with an explicit path is printed.

• There are currently two interrelated experimental features that extend this functionality, in a framework termed feedback providers:

  • PSFeedbackProvider is the basis and provides support for third-party feedback modules, PSCommandNotFoundSuggestion enables additional built-in functionality, notably suggestions for mistyped commands and, on Linux distros with a /usr/lib/command-not-found utility, package manager-based installation commands for not-yet-installed well-known utilities.

  • See this blog post for details.

[mklement0]

@RokeJulianLockhart,leaving the command-not-found handler aspect aside and focusing on the gist of your proposal:

• It is up to each executable to signal the need to run with elevation / sudo:

  • On Windows, applications can use an application manifest to not only signal the need for elevation, but to automatically attempt it on invocation.

    • This is handled by the system itself - no PowerShell feature needed.

  • On Unix-like platforms, there is no such system-level mechanism (as far as I know), and therefore PowerShell cannot discover statically, before invocation, which programs require sudo:

    • Any approximations of such functionality - such as "hiding" sudo-only utilities via a dedicated directory such as /usr/sbin that isn't present in the $env:PATH value of non-root users - are again handled at the system level and require no PowerShell feature.

Therefore, I don't think there is anything actionable here, and - unless you disagree with my analysis - please consider closing this issue.

[RokeJulianLockhart]

#20907 (comment)

@mklement0, it seems that PolKit is the answer, then. Thanks for the detailed responses.