Does this elevate within your own account token (i.e. will not work for non-Administrator users), or does it actually switch user (e.g. to LOCAL SYSTEM)?

Allow $PARENT_PROCESS_NAME to run $COMMAND with administrator rights.

So if you would enter the following in cmd.exe:

  sudo notepad.exe ...

Allow Command Processor Shell to run notepad.exe ... with administrator rights.

Why?

I'm not critical. I don't have enough knowledge on the situation to share criticism on the topic yet.

I could have added "Could you expand on this?" to clarify my intent.

It's a tricky feature to ship, cause it is ultimately something that can be used as an escalation of privilege vector. Like, that's the entire idea. And there are a lot of people who (very rightly) get the ick when you say "we want to add this thing which can be used as an EoP to the OS image".

So, it's kinda hard to believe that after four years of thinking it was impossible, we actually managed to get it out the door.

Great work making this happen!

Thanks for taking the time to answer, very appreciated! You must be happy to have been wrong, ah ah.

The biggest visibility into this issue is software installers, which regularly offer to launch the freshly installed program for the user's convenience...with the same elevated permissions the installer itself uses.

[0]: according to this SO answer, runas still runs the process with high integrity: https://stackoverflow.com/questions/20218076/batch-file-drop...

me: "Why should we be glad that Microsoft is not functional enough to make a decent product...?"

HN: flag!

Can't you call the target program directly? There must be a way, because explorer.exe is not elevated, and when you right click a program and choose "Run as administrator" you get a pop-up for the target .exe, not for Explorer.

> Enable Sudo

> Enables the sudo command

If I were a scammer I could make up an acronym or something that sudo means and trick someone into turning this on because the toggle doesn't actually describe what it is so I can just weave my own narrative.

It's hard to imagine a company that size would name it so deliberately without realizing it would cause confusion in search engine results and such.

A good faith assumption would be they wanted to make Windows more familiar to users of both but it also means that Windows will get mentioned in more Linux results over time to disambiguate it.

same microsoft as where I'm from?

embrace (copy sudo), extend (add incompatible options), extinguish

Yes, we know. Internet Explorer, yada yada. Beyond the ridiculousness of the notion of sudo specifically being a target for MS, the notion that MS, or any company of its size, is THAT single-minded, is absurd.

While I understand picking a familiar name, sudo is certainly not the only player, there's also doas. This shows people can adapt to another name and another name would have seemed more appropriate.

edit: whoops, it was already mentioned in this thread [3]

[1] https://daniel.haxx.se/blog/2016/08/19/removing-the-powershe...

[2] https://linux.die.net/man/8/sudo

[3] https://news.ycombinator.com/item?id=39305452#39309126

The fact that doas has far fewer users, and examples everywhere show `sudo xyz` as the way to run xyz as root, shows that people do not adapt to a different name.

Microsoft has been trying, for years, to get developers to use Windows systems. This is another good step towards doing so.

The answer isn't to use a different name; the answer is to actually support most of the sudo interface.

But that said, there's a subset of the sudo interface that would cover the majority of what most people need on a regular basis:

-H (change home directory)

-i (act like a login shell, which may not be meaningful on Windows but could at least be ignored for compatibility)

-E (preserve the environment)

-u (set the user to something other than root)

-g (set the group)

-s (just run a shell)

The answer is to do either.

i.e. the complaint about using the name while offering a different, incompatible interface is valid.

I do think it was correct to use the name, though, which means they should be more compatible.

Of course, it being an issue is an opinion (of mine), see my daniel.haxx.se link from my other comment next to yours for a motivation of this opinion.

Now "sudo" is not a very Windows-y name for this utility but it has the advantage of being self-descriptive by those most likely to use it. It's sudo... for Windows. You don't have to explain it further.

The command line namespace is flat and there are only so many letter combinations, the idea that an OS shouldn't reuse a command name from a different OS is pretty limiting.

Good point, the unlikeliness to ever run the real sudo on Windows makes it less an issue. Though doesn't remove it completely. You could for instance imagine a bash script (which you can run on Windows, since you can install Bash there) trying to use sudo if present, or something else, and fail because sudo is present but doesn't have the expected features. In shell land, the name of a command is almost an implicit contract.

> The command line namespace is flat and there are only so many letter combinations, the idea that an OS shouldn't reuse a command name from a different OS is pretty limiting.

In practice:

- Programs are mostly cross platform so many "commands" can work on different OS. Which makes the command line namespace quite shared between OSes

- I've not seen many clashes. I can certainly remember of one: the Chromium browser and the Chromium B.S.U game. It was unintentional. The "sudo" one is. You can certainly avoid it.

At a basic level, I’d wager a vast majority of sudo’s usage is very basic, “run this command as admin”. If it can do that out of the box, it solves for a vast majority of users and they don’t have to learn some kind of new cmdlet to be able to do it.

I also can't imagine a different name to cause such a training issue. We are speaking about people who learned using the terminal on Unix and are using it on Windows. They are likely at ease with computers. If they are confused by a name change, I can't imagine how confused they could be at the first difference they encounter. The same name might as well cause more training issues. I'm not convinced.

Linux users can experience this now by using sed on macOS

> it does the same function which is to elevate a unprivileged command

That's only one of the use cases of Sudo. Here's a description of Sudo from the official manual [1]:

> sudo, sudoedit — execute a command as another user

Sudo for Windows can't do that. It's mentioned in its FAQ:

> the sudo command on Windows does not support running programs as other users

Sudo for Windows is like a cat command that can't concatenate files or a touch command that doesn't update timestamps.

[1]: https://www.sudo.ws/docs/man/1.8.18/sudo.man/

[2]: https://learn.microsoft.com/en-us/windows/sudo/

Oh, that's a good counter-example to your own point: 99% of people who use cat don't care about this functionality.

    cat *.txt

Same goes for sudo. If you're going to claim that a whopping 99% of users don't use the CLI options or /etc/sudoers, you'd need solid proof. Because a simple search shows otherwise:

https://grep.app/search?q=sudo%20-&regexp=true

This Sudo for Windows behaves nothing like the actual sudo. It doesn't even achieve the original's stated purpose.

Also considering that search results for anything involving Windows tends to be riddled with spams and outright scams, this will negatively affect non-Windows users searching for sudo as well.

So again, this naming conflict is unfortunate.

That's an astonishing claim to make without evidence. I don't see "cat *" being used anywhere. In fact, I've just ran search for usage of "cat" over the repository of shell scripts that are used for the various packaging and deployment tasks in my company (and we have to deploy a lot of stuff, written in different programming languages, and every team packages their stuff into their docker containers in their own way but it's all still documented in this repo) and every single use of cat is either

a) reading data into a variable "VAR=$(cat file_with_data)";

b) writing inline data from script into a file "cat >>$TARGET_FILE <<EOF ... EOF";

c) an entirely reasonable use of cat "cat file | utility_that_accepts_filenames_too", sometimes even "cat file | utility".

None of them take a pattern or more than one file.

OpenSSL, Curl, Git, Linux, Gettext, NodeJS, zstd, GCC, FFmpeg, OpenJDK, Pyenv

I think users, upstream developers, and downstream packagers of these software will all be upset if cat ceased to concatenate.

Example:

https://sourcegraph.com/search?q=context:global+repo:%5Egith...

UPD: And lots of people use "cat file1 >>output; cat file2 >>output" for concatenation anyhow [0]. Apparently shell already can concatenate things well enough, so cat should do one thing and do it we;l: dump a single file contents to stdout /s.

[0] https://grep.app/search?q=cat%20.%2A%3E%3E&regexp=true

That's because it's a regex search and not relevant to the point at all. What matters is that people use widely advertised features of a popular tool, including sudo and cat. Especially if that feature is the single stated purpose of the tool.

Taking a name of a widely used tool and slapping it on something that doesn't even do what the original was made for isn't a nice thing to do. I don't get why that's controversial to anyone.

> so cat should do one thing

That one thing is con-"cat"-enating files, so to speak. Why should it become something different just to make the name Sudo for Windows appear somehow less misleading?

Also,

    rm out.txt
    for f in *.log; do cat "$f" >> out.txt; done

    { for f in *.log; do cat "$f"; done; } | less

This is off topic, but the Git devs were correct in doing `cat pine patch1 | git am`, since the test in question is

    test_expect_success 'am takes patches from a Pine mailbox'

    cat patch1 >> pine
    git am pine

https://marc.info/?l=openbsd-tech&m=170742832804260&w=2

I would love to see a tighter integration of winget into Windows. I recently used a fresh MS Windows Server 2023 installation and had a bad day to even get winget installed.

I really hope that the current strategy does not turn out as somewhere between "embrace" and "extend"...

Even continually sticking to old design patterns causes issues in development and deployment. Big name companies do not trust applications running on hosted Windows because of their current business practices. Microsoft does not even have a means to provided ease of deployment for air-gap system. This is the only way some big business will let products hosted on Windows to be in their facilities.

Windows as become more problematic for me because of all the layers of security that need to be applied for companies to trust Windows. This causes issues such as having to stop typing because Visual Studios or VSCode cannot process key strokes in real time.

Localization translation text standard still does not allow for containing singular and plural in the same key. Translations should be easily to update so the client can improve wording on the fly. Microsoft still recommends using resx and compiling a DLL.

.....

This is a big issue for me. I'm stuck using Windows for work, and it runs like an absolute dog even on good hardware.

Why to a crawl? Well, I've witnessed multiple antivirus products go bezerk on your dev folder if you compile C++. Turning them off for this folder increased performance by a factor, which is what's typically done and completely subverts the purpose of these products. Also, I witnessed a certain product with a bird of prey that would run for hours and then just crash on a directory with a few million files.

This combination of sub-par quality of "security" products and performative deployment of endpoint security is a bane, at least for me as an enterprise software developer. I don't see Microsoft being primarily at fault there.

(See the transcript of Security Now 958 for recent details.)

Powershell is a super neat language though.... especially if the Microsoft team that manages it would work more with the team that does more for SMEs and not just DevOps. The overwhelming majority of windows users doing regular business work have to deal with crufty stuff like VBA or over engineered stuff like C#. I was really hopeful for Powershell, but it seems like it's almost entirely to serve IT administrators or software developers. I wish that very capable team would do things like add a fairly simple GUI DSL or form designer with the tool. I know it can hook into WinForms, but that's a lot of effort and requires more C# background. There are probably millions of business analysts that would love to build little simple GUI apps without investing weeks of effort. The current approach is to just use Python, but that has it's own bag of problems for those that can do a little coding, but aren't full time developers. It just seems weird that Microsoft never invested in a language for SMEs that would integrate well with the OS and Microsoft apps and tooling.

Give me C# over PS any day.

   $value = 10
   if ($value -eq 10) {
      Write-Host "Value is exactly 10."
   }

The weird part of PS is the piping, which doesn't always do what you think it should as everything is an object instead of text.

  value="1 -o 1"
  if [ $value -eq 10 ]; then
    echo "Value is exactly 10."
  fi

Also, why does the documentation[0] talk about statements returning values? I've never seen the terminology used that way before. Usually expressions evaluate to a value and statements can consist of an single expression.

[0] https://learn.microsoft.com/en-us/powershell/module/microsof...

They could use `==` for equality but then what symbols would -ceq and -ieq be?

What symbols or what else would work for `-match` and `-in` and `-cmatch`?

If they were just `eq` or did use `==` how would that work for when they are actually options to a cmdlet such as `| where-object -eq $x` ?

I also don't even like their verb-noun philosophy because it's impossible to figure out what the commands are and there are so many. It's still all objects and methods underneath but you can't auto-complete anything.

Handwaving away decades of muscle memory and expectations for > and | seems bad, but those are the easy cases, and you've avoided dealing with the operators which are not symbols and the case sensitive/insensitive variants of common operators. What do you suggest for syntax instead which handles all, or most, of the cases PowerShell handles?

We have had "decades of programming language development" but I'm not aware of any which do what PowerShell does. I haven't spent any time on OilShell or NuShell or other Unix-shell-modernised systems, but Python syntax and behaviour does not make for a good shell, nor do any other programming-language-with-REPL that I've used. What language are you thinking of which makes a good compromise of both shell and pipeline and programming language, which would also work in the Windows world where things aren't text (PowerShell design priority)?

> "I also don't even like their verb-noun philosophy because it's impossible to figure out what the commands are and there are so many."

On a computer system where many thousands of things are possible, specifying what to do by command line is going to require typing one thing for every option you need to specify. Whether that's in the command name, in the command options, in the arguments to the options, or externalised in some ENV variable or /sys/ namespace or some /proc/ data source or some /etc or .dotfile config option, or hiding in some JSON structure, it's only shuffling the complexity around. At least with many commands they are organised into modules, searchable, and can have associated help.

> "you can't auto-complete anything."

*date*<tab> cycles through all commands with 'date' in their name. Cmdlets and binaries and functions.

hyper-v\*failover*<tab> cycles through all cmdlets in the Hyper-V module which have 'failover' in their name.

Get-Command -Noun VHD searches for commands with VHD as the noun part of Verb-Noun.

Get-Command -Parameter VlanId searches for commands which take -VlanId as a parameter (e.g. Hyper-V\Set-VMNetworkAdapterVlan).

Also winget does not have python 3.12 which was released 4 months ago.

And you don't have to use --id - you can do `winget install 7zip` etc in cases where there's no ambiguity.

I was able to find the 7zip page by googling for it: https://winget.run/pkg/7zip/7zip

But as with Python the default suggestion is `winget install -e --id 7zip.7zip`. If I can just do `winget install 7zip`, why can't they show that command? Why is the complicated way the default and the simple, intuitive method optional and not easily discoverable?

There's lots of room for improvement.

Those sites give you the command line exact match (-e) --id as a safety precaution so that you install exactly what you were looking at on that website and not a fake or similarly named but different installer or a different version than what you expected.

The complicated way is optional, you are using two different options: -e and --id. The CLI's default is actually sloppier when you don't use those two options in that way.

It seems easily discoverable from `winget --help` to me. But I tend to use `winget search` rather than websites, so maybe I'm just more familiar with it.

For us developers, the changes in Windows to support WSL2 weren't really an enhancement of Windows, it's now just a really complicated way to run Ubuntu. As in, Windows 11 is the biggest Linux bootloader in history.

sudo for Windows...can't even see a use for it any more.

WSL 1 is allowed luckily, but it's kinda meh

Honestly, the hardest part will be porting the Settings app changes to the Windows 10 styles. `sudo.exe` itself doesn't really depend on any OS platform changes, and if it did, we'd have a _very_ compelling case to bring those features with us downlevel.

What issues are your customers having that they need profesional help to upgrade to a new Windows OS?

YEs I was asking seriously. You still haven't explained what those challenges could be. All you do is mock people for their genuine questions without providing any actual answers/information to back up your vage statements.

>You've clearly never worked in any kind of customer support position

Then if that's clear for you I haven't never done that, why would you not understand I was being serious? Why are you being disingenuous here? Or you just enjoy being a troll?

> because businesses and individuals need all kinds of help with a transition like that.

Mate, 12 year-olds in my developing country can run Windows 11 updates/installs for you, including installing pirated licenses and cracks for you if you pay them 5 bucks.

What could be so complicated that the internal IT of a company can't figure out the transition from Windows 10 to 11 that they need to pay outside help for that? Especially that backwards compatibility is one of Microsoft's fortes to make life easier for admins and convince companies to stay in their ecosystem.

Many small and medium companies don't have any internal IT. Maybe the original parent commentor works for an MSP / outsourced IT services provider / as an IT consultant.

> "What could be so complicated that"

Windows 11 has hardware requirements that Windows 10 didn't, their equipment may need to be reviewed/audited or refreshed - planned, budgetted, quoted, ordered, received, checked, configured, user data migrated over for dozens of devices. Business customers need to buy Windows Pro not Windows Home - and need enough IT experience to know that, non-technical companies may have bought some Windows 11, had problems, and needed to call someone for help. A company might have some internal IT who could do it, but are busy with other projects and don't have time to plan and execute an upgrade. Windows 11 comes with new Group Policy templates which need importing to a Windows domain and configuring - and may need reviewing or auditing for regulatory compliance to see what needs setting up and the parent commentor is some kind of compliance person helping with paperwork instead of a technical person. A company might take an upgrade to Windows 11 as a time to change other things like a move to Microsoft Cloud Services (OneDrive, Microsoft account for login) and each user needs to be given a new laptop and have all their settings moved over. A company might have specialist software from vendors who aren't very progressive - e.g. optician's software which manages retina scanning cameras - and needs lots of time consuming hand holding with the vendor support line before the vendor will agree to the move, even if it would in principle work fine. Regardless of technical issues, the upgrade could take an hour or two per machine, over dozens or hundreds of machines, that's either a big interruption which needs planning (staged rollout for different departments, say) or needs some automated way to deploy it which needs setting up, testing, and checking on, and may just hire some temporary contractors for more people to do that. There may be users who could do it, but won't because it isn't their job, or aren't allowed to by their manager or union so it isn't their responsibility if it goes wrong.

Does this mean that the feature set of sudo for Windows can't be similar to the feature set found on sudo for *nix e.g. for BSD, MacOS, Linux..?

https://www.sudo.ws/docs/man/1.8.15/sudoers.man/

However, with that said, in the end the closer Windows gets to Linux/*nix then the easier it is for people to move away.

In that sense, I'll support your initiative.

I really dislike windows but there’s a decent amount of good stuff in there.

it’s just buried under the popups, ads, strange behavior and terrible business practices that are hostile to interop. This helps change that b

IOCP is dope.

Plus it means I don't have to leave the comfort of Tabby.

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

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

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

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

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

Or does runas work differently than I thought?

(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.)

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.)

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

https://www.reddit.com/r/linuxmasterrace/comments/u4xeoy/in_...

I am not asking questions about sudo to someone assuming sudo is specifically Linux software.

When coming up with your sudo what were your inspirations and what does sudo do that you decided you wanted to avoid?

Probably some MS server =|

https://xkcd.com/838/

Alternatively, a stern yet extremely polite mail from Raymond Chen asking what you were actually trying to accomplish.

Every little bit of friction removed is a good thing.

Linux is open source and free, Apple develop an OS that sells specific hardware, and historically Windows has sold the software for generic hardware. Windows is unlikely to become a better Linux than Linux. Where is Microsoft's new business model going?

Historically Office was a money maker, but Office online is a shambles and many users interact with Office via this interface - I see Office slowly dying in favour of open source options. I see Windows licenses being sold less and less in the future. Microsoft Lens is essentially buried at this point. There are the Surface laptops/tablets which are good but not special. Dedicated games console hardware will likely become less attractive as they slowly become glorified desktop PCs.

I don't see Microsoft with big user shares in the software or hardware industries? There were a few good purchases such as Minecraft, GitHub (+), etc [1]. Is there something I'm missing?

[1] https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitio...

(+) GitHub's new security model is outright hostile - to the point I no longer want to use it.

"Microsoft revenue was $198 billion in 2022, up $30.2bn (+18%) from a year earlier. When we do a breakdown by product streams, the largest source of Microsoft’s revenue was Office, with $44.9 billion (23% of the total). Just behind in the second place was Azure with $44bn of revenue (22% of total)." - https://www.kamilfranek.com/microsoft-revenue-breakdown/

Office alone increasing by $5Bn revenue in a year, increasing by $24Bn in ~3 years, being the largest chunk of revenue of the most valuable market-cap company on the planet, that's what counts as "slowly dying"??

It's possible this sudo could have been implement as yet more clunky flags to runas, but it seems like making it a separate tool has benefits: off by default, whereas runas is a nearly always-on required built-in; more importantly a nicer less clunky syntax.

and what's the point of switching when gsudo basically does the same?

exactly how is 'sudo for windows' different than the existing model in windows 10 where privilege elevation is a popup window and you click through it? arguably the current model is just sudo with nopasswd.

how do you reconcile the idea that your effort --without principled reform of the windows security model at a fundamental level-- is just cargo-culting a more successful projects security model?

'Start-Process powershell -Verb runAs' is the same or different than this?

Thanks for caring about security and trying to make things better. its hard, thankless and frustrating (and thats just the windows part ;))

Sorry, this has been lacking for so long that you know... Late to the party.

Any particular reason the source code for sudo.exe wasn’t able to be open sourced along with the announcement of this feature?

Reminds me of when PowerShell decided to have "wget" and "curl" cmdlets that didn't have any of the advanced features of the originals. Naively it sounds helpful. But it introduces confusion.