Hacker News Reader

Comment by Repulsion9513 | Hacker News Reader

Why can't you do this with the tool that already exists to do the exact same thing, called runas?

Does it have a policy editor comparable to the /etc/sudoers file? Sudo is interesting not because it just allows to assume admin privileges for a moment; it allows to give access in a finely-grained manner, and not exclusively admin access.

Just scrolling through the documentation [1] gives some idea. Examples in the end may surprise the reader with the variety of capabilities.

[1]: https://www.man7.org/linux/man-pages/man5/sudoers.5.html

You're talking about Sudo for Linux - today's new "Sudo for Windows" doesn't support a sudoers file.

No, nine_k is talking about the abstract requirements that are understood by "sudo", asking how they are reflected in this implementation.

Sudo is widely understood to refer to a program which allows specific users to run specific privileged commands.

Nitpick: it’s not “Sudo for Linux”, it’s just “sudo” and runs on a wide variety of operating systems aside from Linux. It actually predates Linux by around a decade.

This sudo for Windows doesn't either because it's not sudo. Looking at the docs, it's not even remotely compatible either. The choice of name here is unfortunate.

I have noticed that runas is mentioned as an already existing sudo alternative, but as far as I know, runas asks you for the administrator's password. sudo asks the own user password. This is how you give a non administrator user the right to use some application/tool without revealing the admin's password.

Or does runas work differently than I thought?

You're right, but on my work environment I have two accounts - "me" and "me with elevated permissions". (I don't say "admin" because there's still a bunch of stuff I can't do, like run netsh). I assumed that was the normal pattern in Windows-land?

It is something of the normal pattern, it always seems like companies love it. It always seems like UAC with extra steps to me. It's not that much more secure than taking UAC as-is and dialing up the security settings on UAC prompts to require a password every time. It's often amusing to me that everywhere I've seen require "secondary accounts" for admin permissions has dialed down the overall security settings of UAC below the defaults.

Hacker accesses some legacy application that verifies the user's credentials against LDAP. Maybe it's payroll or something. Hacker logs passwords until someone who happens to be a org-wide local admin (or worse yet DA) wants their paystub. Hacker now has admin privileges.

(Also, if UAC settings are turned down, that might mean the UAC prompt isn't on the secure desktop, and any malware can thus trivially elevate itself if your everyday account is an admin... etc.)

Thats a ... ya no, thats definitely not the default pattern

Right, I don't think runas has a "sudo-mode" in terms of "let the user elevate their own permissions for specific tools even if they don't have an elevated account to elevate to", but runas is so low level and has so many weird combinations of arguments that maybe there is a buried similar way to that, I can't say for sure.

But the base "sudo" case where you have an account that supports UAC elevation (you are your own administrator) runas definitely supports as the CLI way to invoke UAC prompts for your own account, not just other administrator accounts. (Using the /trustlevel flag accordingly, as I recall.)

My question is more why they couldn't add this functionality into runas, rather than making a new tool that doesn't even do what its name says it does :)

A link in the article explains ...

https://learn.microsoft.com/en-us/windows/sudo/#how-is-sudo-...

It only explains what is different between sudo and runas. It doesn't really explain why they couldn't just improve runas and add those missing features instead of creating a new command. As it stands now you seem to need both sudo and runas to cover all reasonable use cases.

Backwards compatibility and changing the security dynamic of existing scripts. I'm sure it is probably possible to achieve using runas, but my guess is that it would greatly delay adding this functionality, as they would have to cover all concerns for which runas is used.

And if you need the Sudo interface there are wrappers like https://github.com/purplesyringa/win-sudo.

If the elevation prompt would show the elevated executable and not the wrapper, that would be news...

Been using it for a decade or more. Came to make this comment.

Also 'start -Verb runas' in Powershell.

Is there anything shorter than `powershell.exe -executionpolicy unrestricted -file`?

  powershell.exe -executionpolicy unrestricted -file ./setup_windows.ps1 -InstallPSWindowsUpdate -UpdateWindows -UpdateChocoPackages

setup_windows.ps1: https://github.com/westurner/dotfiles/blob/develop/scripts/s...

The executionpolicy merely allows you to write unsigned scripts. Not that it runs them elevated.

    powershell.exe -executionpolicy unrestricted -file ./setup_windows.ps1 -InstallPSWindowsUpdate -UpdateWindows -UpdateChocoPackages
    powershell -ex bypass -f ./setup_windows.ps1 -I -UpdateW -UpdateC

(or whatever are short enough to uniquely identify parameter names for your script)

Thx

I really hope that sudo is going to allow one to capture the output of the thing running in sudo and handle errors better. I recently wrote an installer script in PowerShell and had to go through severe contortions to support privilege elevations for only a minimal part of the script. I needed to use start with runas to relaunch the same script with different options to continue the installation process and there's not much in the way of proper error handling either.

Reply on news.ycombinator.com