Sudo for Windows

Yep, it's really happening. Sudo is coming to Windows. It's obviously not just a fork of the linux sudo - there's enough that's different about the permissions structure between OS's that just a straight port wouldn't make sense. But the dream of being able to run commands as admin, in the same terminal window - that's the experience we're finally bringing to users.

I've been working on this for the last few months now and I'm pretty excited to talk about it or answer any questions!

I think they should've named it something else to avoid confusion, especially if it doesn't have the same behavior as unix sudo. If it has different arguments and features, imagine the confusion of unsuspecting users searching how to use sudo in the future.

I disagree. Although this "Sudo for Windows" is not a one-to-one port from Linux, it does the same function which is to elevate a unprivileged command. Imagine if they announce "Introducing Dosu for Windows", you won't know what the hell that is without reading at least the first paragraph.

In addition to not being a one-to-one port, Sudo for Windows is a completely unrelated command.

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/

like a cat command that can't concatenate files

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

That's an astonishing claim to make without evidence.

    cat *.txt

is a pattern I see being used everywhere.

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.

"cat *.txt" is a pattern I see being used everywhere.

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.

UPD: I've ran "cat *\." on the grep.app, and it seems that it's used mostly for bulk log processing; I vaguely recall we moved away from it to using custom reader scripts because the asterisk doesn't expands into the files ordered the way we needed.

The onus isn't on me to disprove that 99% of cat users don't care about concatenation, but here's a non-comprehensive list of projects using cat to concatenate files:

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

Half of those examples from git don't even invoke cat, another quarter don't concatenate files, and the final quarter use it for preparing test data. Well, I guess the last is a valid use although again, most of those uses could've used printf "$chunk_of_data" >>output instead of writing temporary files all over the temp directory, and I imagine the "git am" test could've been written as "git am patch1 patch2" instead. shrugs I guess it's 80% then.

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

Half of those examples from git don't even invoke cat

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

is a clunky way of concatenating files.

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

Even clunkier.

Windows and Linux already share dozens of commandline commands with the same name and have different behaviors.

This doesn't mean this isn't an issue, and that the issue should be worsened.

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.

The situation with curl is different because these are unix utilities you can run on Windows (hence the issue).

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.

The situation with curl is different because these are unix utilities you can run on Windows (hence the issue).

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.

Either way it’s done it’s an issue. Use a new name and it becomes a training problem, even for the most basic usage. Make it the same name and people expecting certain behaviors might get something slightly different.

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.

This can't fully address the concern I raised. Their curl alias addressed the most basic / common usage and it caused issues.

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.

Not like it's unique to Windows. Linux and say FreeBSD are similar in this regard as well, lots of commands with same name but different behavior.

They've done it with curl: they made an alias to their own program not supporting the same feature set and it inevitably backfired [1]. sudo is a complex program with a lot of different options [2] and as people from MS said here, it's never going to be compatible because of how Windows works differently.

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

sudo is certainly not the only player, there's also doas. This shows people can adapt to another name

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 isn't to use a different name; the answer is to actually support most of the sudo interface.

The answer is to do either.

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

Yes, I agree.

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

Using sudo for a Windows program doesn’t seem as bad as using curl as an alias for Invoke-WebRequest. While the real curl can be installed and fully functional on Windows, sudo is intuitively an OS-level program that deals with OS-level access control.

imagine the confusion of unsuspecting users searching how to use sudo in the future.

Linux users can experience this now by using sed on macOS

Or by using a bash builtin that duplicates a normal command.

People can experience confusion on any operating system by using sed :)

To be fair, you will probably be confused by using sed in general

that's the standard microsoft way

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

I can say with 100% certainty that Microsoft is not going to extinguish sudo

“Please watch this in-terminal ad while you enter your password”

This really goes to show that no matter how legitimate a viewpoint (Microsoft is into EEE), there are always people looking to pretty unintelligently bandwagon.

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.

> especially if it doesn't have the same behavior as unix sudo... imagine the confusion of unsuspecting users searching how to use sudo in the future.

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.

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.

same microsoft as where I'm from?

So it's just some black hat SEO to seem more relevant to Linux users?

You are not the only one thinking so. There is already a thread on OpenBSD's tech@ taking swipes at the obvious naming collision:

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

I just hope it's not in the PowerShell zeitgeist of `--Super_Long_Option_Names_that_Use_a_Mix_Of_Caps_And_things`

perhaps `admininator`

Nice to see the author here! I have to say: I really like whats going on in Windows world from a developer perspective in the recent years. I am a hardcore Linux fanboy for decades but I have to admit that PowerShell, WSL, vscode, Windows Terminal and the recent open source strategy sounds very appealing to me. This is something MS/Win does much better in recent days compared to, for instance, Apple/Mac OS.

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

Only problem is Powershell's commands are abysmally slow in comparison to chaining together Linux terminal commands that are written in C.

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.

Powershell is a terrible "language". It's fine for sysadmins to do sysadmin work but why would you want to subject business analysts to that level of unix shell inspired weirdness. Microsoft already has VB.NET which would serve that market much better.

Give me C# over PS any day.

It’s not Unix shell inspired at all, that’s the problem.

Oh it is, just in all the worst ways. I mean look at this:

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

At least it doesn't let you do this (as far as I can tell) so it seems slightly better in that aspect:

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

The syntax is terrible, though – if these operators are not actually options for a command, which is the context where the leading dash makes some kind of sense, why make them look like that?

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

Perl users feel right at home.

I actually find that very readable. What is the problem?

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.

That is actually an advantage.

Terrible? For writing GUI yeah, sure, not that it was designed to do it. Just it's possible to tap into .net world, that's all.

VB.net is still .NET which is fairly complicated and verbose. It's basically just a visual basic skin over C# right?

I'd love to see winget with a command structure that makes sense. Currently if I want to install python via winget, I have to run `winget install -e --id Python.Python.3.11`. -e? --id? What are these for? Why do I have to memorize them? Almost every other package manager just does something like `packagemanager install python`, and then you can supply args for versions if you like.

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

winget has Python 3.12.2 at the moment, which has been released two days ago.

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

It doesn't turn up here, maybe I'm on the wrong website? https://winget.run/search?query=python%203.12. For that matter 7zip doesn't show up in that search either.

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.

winget.run is no longer updated. Try https://winstall.app

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?

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.

Windows change is welcoming, yet still not quality. As stated by someone below, sudo is https://www.sudo.ws/. Microsoft should give it a proper distinctive name lie wsudo or psudo. Little thinks like is compounds the issues with Windows / Microsoft.

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.

.....

Is that really what companies have to do to "trust Windows"? From my experience, it's rather driven from the need to look compliant. Thus, managers without in-depth knowledge decide to buy "endpoint security solutions", the more the merrier, deploy them to your machine, and that brings things down to a crawl.

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.

Most businesses that use Windows and/or Microsoft products do no go through all of that. The main benefit of using Microsoft is all of the integration between development products and DevOps. Most of the solutions for security are not provided by Microsoft, and often are looking to check off boxes to make auditors feel better, without actually enhancing anything. I've had to create some bizarre workarounds just to get past auditors, and in the end the solution was no more secure than doing nothing at all.

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.

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.

Thanks! I think the team we're on has a very clear focus on making developers happy. Like, we're all ourselves, developers, so a lot of it is very self-serving. Anything we can do to make our own lives better is probably going to be a good thing for a lot of other developers too.

Shame the rest of the company is dedicated to making users unhappy to scrounge a few extra pennies. Users include developers of course.

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

I use WSL2 a lot because my current employer is a "Microsoft" shop (despite all the code being deployed in Linux containers).

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.

you are lucky, where I work WSL2 is blocked for security reasons

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

Does the UAC prompt always say "Verified publisher: Microsoft"? Even without controlling stdin, malware at medium integrity could prompt to run a malicious command, and users will only see Microsoft's good name in the popup.

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

Putting Microsoft in the UAC prompt is indeed weird. It should be the info of the target binary. This feature sounds a bit rushed, and it's early preview, maybe they fix it by the final release.

Yea, that's a limitation of UAC at this point, and probably not one we can avoid. The "Show details" dropdown on the dialog does however show the commandline you requested, so at least that's one way of making sure it's the thing you ran

The best way would be, if it could say something like:

Allow $PARENT_PROCESS_NAME to run $COMMAND with administrator rights.

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

  sudo notepad.exe ...

It would say:

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

Maybe for Windows 2025 we can work with the UAC folks to get something like that. I'm still shocked to this day that we managed to ship this at all. One step at a time :)

I'm still shocked to this day that we managed to ship this at all

Why?

Sorry, have you never read anything about Microsoft before? I'm not sure why people are being so critical of OP.

Look, I'm genuinely curious and we happen to have a MS dev here who could provide interesting first hand insight.

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.

To answer the original question: I've been at MSFT like, 8 years now? And this is probably the third serious attempt my team has made at Sudo for Windows. (I think I heard of a couple other attempts in my tenure as well). After the last attempt, my mantra had always been "this is impossible to actually ship".

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.

You must feel like you just shipped Duke Nukem Forever.

Pretty fair, especially since there's already tons of ways (albeit far less convenient) to accomplish nonmalicious escalation.

Great work making this happen!

Makes sense.

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

I wish my fellow posters could get out of their own way long enough to congratulate you! this is a great feature. I'm glad you got it into the build and I can tell you're excited about it. I can't remember the last time. I was excited about a feature that I shipped. maybe I'm just burned out but it's really refreshing to see it's shining through your replies. companies like Microsoft and Google need more engineers like you that actually care about shipping cool shit.

A tool like sudo should probably be sufficiently integrated with UAC to be able to customize that dialogue box...

You say that like Microsoft isn't an incredibly deeply dysfunctional company with absurd turf wars and conflicting interests between all the teams. You'd think it should be sufficiently integrated, but it's likely office politics made that impossible. How about be glad we got this at all as a first step, then maybe it will build momentum towards a better integrated solution?

You forgot that because of backcompat this solution will now become the unchangeable standard for years and anything more integrated will be in addition, not a replacement.

And that's OP's fault how? We often have to work with the environment and framework we have, not the one we wish we had where we could just immediately implement the best possible solution.

From the diagram on the article I see that sudo is elevated first, then the target program is launched.

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.

Maybe until UAC is improved you can ship with a launcher process that is signed by publisher "Unknown"?

Yes, but then you would just run sudo cmd.exe [the program you want to run] and it will still say Microsoft.

Also the preference should actually describe it better

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.

I think you're overthinking this. At the point that the scammer is getting the victim to change settings, overcoming UAC is not the problem.

Can't you already do that today with cmd.exe?

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.

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.

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.

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.

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

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.

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.

The real question is, where will incidents be reported to if you're not in the sudoers file?

The boring answer would be the event viewer snap-in.

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

ASCII Clippy appears: "It looks like you're trying to do privilege escalation"

Isn't that followed by "Would you like me to help you with that?"

They'll be sent directly to -- MARK --.

So harsh right? I felt bad the first couple of times even if it was my own computer!

The people demand to know.

You'll be asked to enable .NET and Simple TCPIP services, and a mailbox file created under C:\ will open on Notepad every logins thereafter.

My fingers are still starting to shake if I accidentally miss-typed the sudo password 2 times. Even on my own server, where the incident will be reported to myself!

billg@microsoft.com

To Santa of course

I still to this day feel like I'm being snitched on, even if I own the hardware directly.

Probably some MS server =|

Santa Claus, if XKCD is to be believed

https://xkcd.com/838/

Can you share if this will ever come to Windows 10, or will it be a Windows 11+ exclusive thing?

I'm not even sure Win11 is on my company roadmap, much less anything cutting edge like an insiders release. Windows 10 Enterprise compatibility is pretty much required for widespread adoption of Sudo for Windows.

Windows 10 is EOl next year. I would bet your company has plans to move to 11 at some point in the near future. I work with customers daily to help to move to 11

> I work with customers daily to help to move to 11

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

Is this a serious question?

Did I stutter?

Apparently, because you can't seriously be asking that question. You've clearly never worked in any kind of customer support position, because businesses and individuals need all kinds of help with a transition like that.

Already working on it :) You can follow https://github.com/microsoft/sudo/issues/2 for updates.

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.

Where exactly is sudo.exe? It doesn't appear to be in the repo. I don't need the Settings portion. The exe itself would be immensely useful.

Same here. Would love it on Windows 10 and Windows Server 2016+.

My left leg for Windows Terminal on Server 2016

..there's enough that's different about the permissions structure between OS's that just a straight port wouldn't make sense.

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

Does sudo supports ACLs (which are the basis of Windows security model)?

Sorry, I don't know.

It has it's own config file and can be configured to do just about anything:

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

Isn't running commands as admin, in the same terminal window, already possible via the use of runas.exe? Granted I haven't daily driven Windows in years but IIRC that does the job albeit with clunkier syntax.

runas doesn't support "same terminal window", it always has launched a new window.

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.

I've been using the 'sudo' that scoop offers for a while, and it has always done exactly what I wanted and completely removed the hassle of having to open a new cmd/powershell with 'run as administrator'.

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

Back when I used scoop, I uninstalled that right away because I didn't like how scoop installed it on its own.

Does this mean that I can run PSWindowsUpdate in a remote PowerShell session? If so, this is going to save me a lot of time. Also, AD management tools never work vie Enter-PSSession. Will stuff like that work as well?

This is good, while I know RunAS exists, I'm more likely to run another terminal with admin than learn how to use it, if sudo is there I'll use that.

Every little bit of friction removed is a good thing.

I haven't seen anyone ask the important question: Is the mascot coming along for the ride?

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

i guess id say thanks for all your hard work, but i dont use windows.

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

Great to see this on Windows! Hopefully this is much easier than using the runas command.

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

didn't runas exist for ages?

Why don't you guys just use a regular shell? People just want a unix like command line. Windows seems to be doing a lot of work to avoid this.

It seems interesting to me that Windows integrates more and more elements of Unix.

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.

I think there can be harm done when a re-implementation, especially a heavily divergent one, takes the name of an existing program. There's a reason OpenBSD introduced "doas" instead of calling their new thing "sudo".

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.

the real question is... isn't it pointless if you still get UAC prompt and cannot just log in via CLI?

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

ha, thank you! I don't need it often but I have cursed for the want of it in Windows powershell.

scoop install sudo.

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

What are the common points with Linux, and the differences?

I am a Linux user but am interested in the architectural decisions you have made. I use doas and I know there are other alternatives.

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

sudo (1980) is older than Linux (1991).

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

If it's just an alias for "runas" that presents a UAC prompt window I will be disappointed.

Initially I thought ur concern is crazy as hell, because who would implement it in such a painful way?

But then I read

When elevating a process from the command-line with sudo, a UAC dialog will appear asking the user to confirm the elevation:

LOL

But it seems like there are other ways to use it without this dialog

In this configuration, sudo.exe will launch a new elevated console window and run the command in that window. The new window will be launched with the same working directory as the current window. The new window will also be launched with the same environment variables as the current window. This configuration has a similar flow to the runas command.

Having the sudo command open an entirely separate terminal as an admin user is absolutely ridiculous and completely on brand for Microsoft.

Along with the UAC dialog, I can't think of a worse way for sudo to behave.

What's wrong with entering your password for sudo? How is UAC more secure than a password?

If you’re running as local admin you just get the dialog, but you’re not using a local admin as your daily driver user acct, right? ..Right? :)

If you’re logged in as a standard user, UAC prompts you for new username and password to authenticate and authorize the privileged operation.

Seems like a horribly convoluted way to manage permissions. Also I have never heard anyone suggest you shouldn't use a local admin account. That's the exact problem UAC was meant to solve.

Having used an unprivileged Windows account, all I can say is no thanks. It's a huge burden if you do anything even slightly more complex than Facebook and email.

As a blanket policy at work, all programmers are admins, everyone else is not. Except when someone is doing a task that requires elevation every five minutes. I'm the only admin on site and it's an unbelievable waste of my time to sit next to someone so I can put in my password every time they click a box. We make those users admins because there's simply no other way to manage it.

Nobody does what you describe. When someone has a genuine need for local admin access, they are given two accounts - an unprivileged account to log in with, and a privileged account to enter into UAC when needed. It would indeed be an unbelievable waste of time to make your IT staff sit next to users to enter admin credentials, which is why nobody does it.

And for the record, "don't log in with a local admin account" is a very commonly recommended best practice for Windows environments. It's unusual that you've never encountered it.

"Nobody does what you describe" is a very... broad statement. I can tell you that "all devs are local admins" is indeed a very popular policy, and has been the case everywhere I worked in the past, oh, 20 years or so - including Microsoft itself.

Another one is local admin account is only temporarily assigned via tickets, with tracking tools every time one needs to log in as admin.

And on UNIX, I have worked plenty of times where no one gets root on the shared development servers, other than IT folks themselves.

Nobody does what you describe.

Counterpoint: I've never heard anyone do what you describe. Therefore no one does it, even though you've just described to me who does.

What exactly is the threat in using a local admin account? I can't think of anything you could do that wouldn't show a UAC prompt. The entire point and purpose of UAC was to prevent malicious elevation without the user's knowledge. I'm really not sure what you accomplish by adding a password to UAC prompt the user wouldn't have read either way. The end result is the same.

Additional work for IT when people screw up their machine.

I have worked in companies where local admin accounts would be given temporarily for like one hour, after submitting a ticket with a reason.

This was partially automated via a desktop application.

Opening another terminal is one thing this new sudo can do. It's also possible to configure it to run the sudo'd command inline in the current window (mentioned in the linked blog post); there are security tradeoffs to consider.

A terminal password prompt can be intercepted by a keylogger and similar things.

UAC is safe from that.

UAC is less secure than a password right?

There's no way that second use case doesn't show a UAC prompt.

The whole point of the split token / UAC elevation is to avoid elevation without user interaction. Imagine malware stuck as standard user just running itself like:

cmd.exe /c sudo malware.exe

Isn't that what askpass does in every modern Linux desktop UI?

Yes, which is why it's silly for people to act like there's something wrong with MS doing the same. Some people will grasp at any straw to bash MS.

to bash MS

Well, now we can sudo them.

Yeah. But I think their point is that there should be a CLI equivalent of the UAC for Windows “sudo”

runas allows you to run programs as other users, including but not limited to as administrator. This funtionality is on the roadmap for the sudo command, but does not yet exist.

Seems like it's not an alias.

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

We already have runas for years now.

This looks like one of those KPI fulfilling projects.

This looks like one of those KPI fulfilling projects

It actually wasn't. This has been one of the top community requests for the Windows Command Line for years. Literally, for like, the entire 8 years I've been here, we've been talking about if there was a way to do Sudo for Windows.

This was done because it makes developers happy, plain and simple. If that's a KPI, then that's the one we're optimizing for.

There are several ways to do sudo for Windows already, to the extent this program does sudo for Windows.

In other words, you're not actually solving the reason people are asking you for sudo for Windows. How do I configure my sudoers policy to allow someone to run a specific application (and only that application) through sudo? THAT is the magic of sudo. Sudo is not just "use your own password for root" like you seem to think it is.

I live by a one step at a time philosophy. It's better to make some incremental progress here, now, and open the door for future progress in this space too. Just like the Terminal - what we're putting out here in the first versions is just the first thing we feel comfortable with people using. We've got lots of ideas for more things to add, just, one step at a time :)

I don't know why people are so negative on this project. I already know about gsudo and yet I was still happy to see an official solution! Even if it were to never evolve, not having to pull a third-party executable in is always nice.

Thanks :)

I'd say waking up today to all this... negativity? was kinda a bummer. We've been working hard on something that people (myself included) have been asking for _for years_.

Like, obviously, it's not perfect out of the gate. That's fine! It was a haul enough to ship this in any form. Now that it's out there, we can make more and more improvements. One step at a time.

Sometimes, I just need a break from the internet I guess.

What is different about sudo vs runas?

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

Seems like it could be done by adding new features/flags to runas?

And then maybe creating alias to sudo in PowerShell like it does for other things.

Surely by people trying to do UNIX on Windows.

That requires you to open an new terminal window. You've never been working in a standard terminal, tried to run a command that requires elevation, and been annoyed that you have to open a new window losing your command history?

Or forgot to Run As and opened a non-elevated terminal by accident?

"In this configuration, Sudo for Windows will open a new elevated console window and run the command in that window. This is the default configuration option when sudo is enabled"

That's the default option but you apparently can still run the elevated command in the current window if you want.

Just like when using runas.

https://learn.microsoft.com/en-us/previous-versions/windows/...

I believe the new window is to prevent SHATTER attacks (https://en.m.wikipedia.org/wiki/Shatter_attack), to ensure that a higher privileged process has a higher privileged Window. Is that not a concern anymore with this new sudo, or is there some other mitigation involved not?

EDIT: from the linked wiki page, "By design, all services within the interactive desktop are peers, and can levy requests upon each other. As a result, all services in the interactive desktop effectively have privileges commensurate with the most highly privileged service there."

The comment in the article links to this explanation:

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

Thanks for the link, is this the only benefit?

You can choose to connect the elevated process to the current console window with the disableInput and normal configuration options. This is not supported with runas.

I also thought that using current environment vars you have set/changed in the terminal is an extra benefit, but that's not listed, so it's not?

First time I've ever seen someone mention it, all the setup instructions I encounter always just say open an elevated terminal.

Runas /user:administrator "application.exe"

Think this might be why it's not very well known compared to sudo.

Interesting. I've been pretty happy with all the Unix-related updates they've put out lately. WSL has been a godsend and the new terminal and powershell have worked a treat. Glad they seem to be continuing with it.

My theory is that Microsoft is working on eventually moving Windows over to the Linux kernel, and all these things they are doing are setting the stage and preparing for an easier transition.

As I said on the other post, I strongly doubt that. It offers few benefits and many roadblocks. It would be a monstrous amount of work, would throw into question many existing security-related certifications, break Microsoft's love of backwards-compatibility, etc.

All MS is trying to do is make it easier for developers to develop on Windows for Windows, which it has ample incentive to do both internally and externally.

I have been continually disappointed that Microsoft has not released a seamless Windows virtualization system. WindowsX would run the new, redesigned APIs, but all of the legacy could run inside a sandboxed system to give the world the required decades to finally transition.

Windows Subsystem for Windows?

Already exists, read up about "Windows on Windows" and "WOW64" :)

It’s basically what Apple did when moving from OS 9 to OS X. Old applications would load up in Classic, allowing users to start using the new system, while developers had time to update their apps.

How about, “Winception”

There have been experiments along these lines for some time now. E.g. there's https://learn.microsoft.com/en-us/windows/security/applicati...

And before that, some people might remember https://en.wikipedia.org/wiki/Virtual_PC#Windows_XP_Mode.

I'm really amused that the least painful way to develop for Windows on Windows is to just use Linux.

the least painful way to develop for Windows on Windows is to just use Linux

Eh? Even as a joke, I don't get it.

1. Download Visual Studio 2022 Community Edition

2. Select and install the workloads you need

3. Fire up any boilerplate from the Welcome menu

4. Press the green play button

Sure, it's no `pacman -S base-devel && g++ main.cpp && ./a.out`, but it's not as bad as everyone puts it.

It is a GUI-first operating system, and if you want to write a fast, HiDPI-aware Win32 application today that supports everything from Windows XP to Windows 11 that's < 50 kB, you absolutely can.

Replying to

All MS is trying to do [with WSL] is make it easier for developers to develop on Windows for Windows, which it has ample incentive to do both internally and externally.

if you want to write a fast, HiDPI-aware Win32 application today that supports everything from Windows XP to Windows 11 that's < 50 kB, you absolutely can.

I said "least painful", not impossible. The scenario you describe here would be very painful.

The scenario you describe here would be very painful

On the contrary, it couldn't be easier. Visual Studio comes with a Windows XP platform toolset[1] that is a one-click install.

Compare, on the other hand, how ridiculously hard it is to develop targeting older glibc on a newer glibc host. There's no way around it except to use a Docker container (which IMO is equivalent to using a sledgehammer on a tiny nail).

[1]: https://learn.microsoft.com/en-us/cpp/build/configuring-prog...

Microsoft's love of backwards-compatibility

This is like, the primary reason to do this move. Wine has better compatibility for windows software than windows has now in my experience.

It's far easier to port Wine to run on modern Windows than to port Windows to run on a Linux kernel.

It's also far easier to port an old Windows application to run on modern Windows, or write a program on modern Windows targeting old Windows, than it is to do any of this on Linux.

This comment reminds me of the GIF of Michael Scott screaming 'NO GOD PLEASE NO'[1].

It also tells me that anyone who makes this comment has limited exposure to comparative kernel development. I've always said it, I'll say it now, and I'll say it in the future: the NT kernel is by far the best part of Windows, and it is in many ways superior to the Linux kernel. Furthermore, Windows ships with an absolute metric ton of very nice userspace technologies that either a) don't exist on Linux, or b) are rubbish to use on Linux.

I don't understand why people want everything to converge on the Linux kernel and its userspace. I like open-source as much as everyone else, but 'let's make ALL the things GNU/Linux!' just leads to lack of competition and therefore stagnation and no innovation.

I have a better wish: Microsoft should open-source core Windows technologies, and eventually, the NT kernel itself. Then, it could maintain its official Microsoft® Windows™ distribution with support contracts, while allowing developers to compile and modify WindowsOpen. Something like what it currently does with VS Code.

[1]: https://knowyourmeme.com/memes/no-god-please-no

Those folks fail to understand that if that ever happens, it will be a macOS UNIX like experience, or Android/Linux, or ChromeOS/Linux, not a Stalmman's GNU/Linux one.

This will be a very controversial prediction, but mark my words: Windows will eventually use the Linux kernel.

Windows NT linage has supported UNIX since day one.

While the original support wasn't great, SUA was quite usable, until they decided to discontinue it on Windows Vista.

Nowadays we have WSL, which makes more sense, given how many folks buy Apple hardware and then complain UNIX isn't GNU/Linux.

Windows NT linage has supported UNIX since day one.

yes, that's why the attempt to provide a Linux subsystem on top of the NT kernel (WSL1) was so successful they abandoned the approach entirely

WSL2 runs the full Linux kernel in a sidecar VM

Also known as, you don't know technically anything about Windows.

There is a very big difference between supporting UNIX, and Linux kernel syscalls ABI on top of pico processes, the technology from Drawbridge kernel taken out from Microsoft Research, which incidentally is also used to port MS SQL Server into GNU/Linux.

who cares? they still abandoned it

because it didn't work

You don't that is for sure.

As for the rest I could provide examples of how the BSDs and Solaris failed in similar attempts to clone Linux syscalls table, despite being UNIX, before Microsoft's attempt, but who cares?

You don't that is for sure.

correct

As for the rest I could provide examples of how the BSDs and Solaris failed in similar attempts to clone Linux syscalls table, despite being UNIX, before Microsoft's attempt, but who cares?

the BSD approach is still supported and part of FreeBSD, so presumably someone cares about that

whereas WSL1 is dead

I don’t disagree. How I think it will happen: Backwards compatibility will start to stray at Microsoft (their last bastion), leading to WINE becoming the go to tool for backwards compat support. Microsoft will create a linux variant or maybe just a DE and the rest will be history (just as Libre Office has begun to supersede MS Office). It is a matter of will and time that C-Suite will want to eliminate labor around Windows to maximize profits as it becomes more and more hardened in it’s feature set. Why maintain when you can utilize FOSS?

In what business segment is Libre Office superseding MS Office? Furthermore, NT supports "personalities". Why bother with a full Linux kernel when they could adopt the personality a la SUA?

Superseding in compatibility. I’m not talking about business segments.

They don’t have to adopt it, they will probably fork it.

I hope you’re right! They sort of did the same thing already with Edge given it’s just Chromium under the hood.

Reminds me of a specific thought experiment with a boat.

The Ship of Theseus https://en.m.wikipedia.org/wiki/Ship_of_Theseus

(For today’s 10000 (https://xkcd.com/1053/))

Just before that: Microsoft will buy Canonical

It already does - SQL Server for Linux runs largely unmodified Windows userland on top of Linux kernel.

https://www.microsoft.com/en-us/sql-server/blog/2016/12/16/s...

Why not just keep the existing kernel running with a small team? Drivers and backwards compatibility are critical to many of Microsoft's enterprise customers.

Now that isn't necessarily true for Windows running in the cloud. Drivers don't matter as much there.

I strongly doubt they would ever do something that drastic. It offers few benefits and many roadblocks. It would be a monstrous amount of work, would throw into question many existing security-related certifications, break Microsoft's love of backwards-compatibility, etc.

What's the difference from opening a Terminal (Admin) window? Just that you can run a single command as admin? I must be missing something here

Opening a terminal in admin window which means any commands you put in that windows will always have admin privilege, no matter what.

What does Sudo is to only provide the root/admin privileges for specific inputted command. Once it is done, it goes back to user privileges. This way, the terminal window didn't need to end the session to go back to user privileges.

Why is admin privilidge even a thing? Ask for the god damn specific resource you want access to and I'll answer yes or no!

"Admin"'s identity is the resource you're asking permissions to use. If don't want identities, are you going to manually authorize every file that needs to be interacted with? For a recursive delete of thousands of files?

You would authorize deletion in a specific directory.

Is that the shiny new capabilities based future that never arrives?

That's a very slim proposition value, especially when multiple commands in a row require admin privileges.

Good thing they're keeping the admin terminal too so you can just keep using that.

Personally I think it's way more likely the admin command is the one off like installing something, changing a setting and then everything else before and between it are user commands that don't need to be in admin space most of the time.

That's like saying (in a Linux context) "sudo is dumb because you can just use su". The two tools have different use cases.

Sudo also allows you to control which commands can be elevated to admin.

It also lets you elevate to admin without knowing the admin password, you elevate with your normal account password. Effectively, some commands can execute as admin, but the user generally cannot.

So you can allow limited administration without giving everything away.

Just that you can run a single command as admin?

I mean, that's sudo's whole thing! [1] You can live your day to day terminal life without the risk of borking things too badly, then when you occasionally need to elevate to higher privileges you can do it easily for that specific command.

[1] Technically not the whole thing obviously, but it's a very common use case.

That has nothing to do with sudo; you could do the same with su -c long before sudo existed...

It's faster and it keeps your current directory, opening a new Terminal starts in the default directory.

It's a convenience thing.

This smells like when PowerShell aliased curl and wget to a completely different command, with incompatible arguments.

https://github.com/PowerShell/PowerShell/pull/1901

Yes terrible move which will lead to much confusion and consternation in the future.

But honestly I'm most amazed by the fact that there wasn't previously a way to run commands with elevated permissions in Windows. How did people work like that? Just run everything in an admin terminal super unsafely?

You have to think about what terminal you need before opening it. I rarely need an admin terminal. That software is often installed by downloading and double click helps as that cuts out the command line. Devops is tricky though! You sometimes have to spawn other processes to get the elevated permissions.

I guess the reason it strikes me as strange is, on linux the usage of `sudo` helps you understand which operations might be dangerous in a fine-grained way

So like if you are executing a series of commands, the one requiring admin privileges tends to be one you might want to be more careful about (i.e. altering system configs, or doing a potentially insecure operation)

So if you are running everything in an admin terminal, it seems like you wouldn't have that extra check to remind you to be extra mindful of a particular operation, since everything you do in that terminal is in the same bucket

I think generally people rather treat everything they do in the admin terminal as dangerous, and do everything else in another terminal or in the GUI. The typical windows admin experience happens on a GUI, even when remoting in, so the idea of using multiple windows for multiple things is more natural than in the SSH experience typical in the linux world

There is runas to run as a different user. And if you want to run as the same user but elevated, there has been third-party software like gsudo [1]. But yeah, the recommended way to do it was to just open an elevated terminal, run the one admin command you need there and close it again. Not a huge deal if all you want to do is run a choco install command or something; and generally you don't switch so much back-and-forth between needing admin and not needing it.

1: https://github.com/gerardog/gsudo

As a self-identified linux engineer who, despite tremendous efforts to avoid it, has somehow managed to still spend about half my career having to care about windows in some way... the answer to "how do you do [thing] on windows sanely?" is generally "it is simply done insanely instead."

Am I biased? Haha yes, I have a signed copy of Free Software, Free Society. But also I have spent years caring about products that do need to work on windows. And my professional take is "there is always a way to do it, but it is very seldom pretty." (And my take for linux is "there is always a way to do it, often more than one, and at least one of them is going to be pretty, but which one is the pretty one will depend greatly on who you are and what you're doing").

As a regular Windows, Linux (via WSL), and macOS user, I'm not confused by the curl/wget alias in Powershell, and I appreciate it. I understand from context that it's not actually curl and has different options. It's much easier than remembering whatever Invoke-HyperText-Transfer-Protocol-Request -Url incantation that's native to Powershell.

Sure, it's not confusing once you know about it and remove it.

But, when you install the actual curl and it doesn't work the way you expect, then it's both irritating and confusing. Horrible choice by MSFT.

Another commenter in a different thread mentioned wsudo could be a better name and I was thinking the same.

It doesn't really bother me personally either way, but I understand peoples' concern. I didn't mind the wget and curl aliases. I find myself autopilot typing 'ls' in PS quite often and I'm glad they aliased it to 'dir'.

OpenBSD's team has already reacted and added Word to OpenBSD

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

* https://news.ycombinator.com/item?id=39309638

If everyone thinks this is so great (just judging by the number of times it's appeared in the HN top 30), why don't they just run linux, instead of some sh!t immitation?

Everyone knows, if you can C colon, your running a M$ product...

Linux is just some [explitive deleted] imitation of Unix, where the sudo command originated.

I run Windows as my primary development environment because it's better. Linux and other OSes run in VMs.

I don't think you should be downvoted for answering parent's question. It's helpful for understanding a mindset that not everyone possesses.

Which version of Windows do you currently run, and what do you feel Windows has or does that makes it superior for your development work?

I run Windows 11. It has first-class support for Linux, with WSL, and the Windows Environment has first-class support for NVIDA graphics, popular productivity and entertainment software. It's reliable, stable, and performs well, with commercial support and scheduled major and minor updates. It's consistant. I can develop software for Windows 11 and be sure that everyone else with Windows 11 can run it.

Windows 11 has ads in its file manager, right?

Most of the complaints I hear are from people running an unlicensed copy and complaining it nags them.

I've heard this as well, but I run windows 11 for work, and can confirm the file manager has no ads in it (I don't know if there are alternative versions of Windows 11 that do, but it definitely isn't true as a blanket statement)

Not GP but Windows-primary as well. Linux desktop has improved a lot over the years, I quite like KDE Neon, but lack of any viable RDP alternative is a deal-breaker for me (I've tried all the alternatives, they're not there). I've never been a consoles-only guy, even though I grew up with DOS. I also rely on RDP to separate work and home machines.

Windows also stable and performs well, ie no silly kludges needed like oom-killer.

I usually stay a bit behind the curve, roughly keeping with the old "don't upgrade until service pack 2 is released" adage. Just installed Windows 11 on my work machine, running Windows 10 at home.

Legally, FreeBSD is just an imitation of Unix.

Linux is just as much of a Unix as any OS in actual widespread use.

There are other real UNIX to chose from.

Next: systemd for windows?

Already there. Windows has had services for a long time managed pretty similarly to systemd/launchd.

Well, compare how to start syncthing automatically on Windows: https://docs.syncthing.net/users/autostart.html

On Debian I could just type:

systemctl --user enable --now syncthing.service

Native systemd on Windows would be awesome. Microsoft should hire the creator of systemd...

Powershell exists.

The manual GUI steps could be replaced with single command line on windows too.

https://learn.microsoft.com/en-us/windows-server/administrat...

There's sc[1] on Windows for this, though many services can do it themselves, eg

    myservice.exe /install

Of course, the application must support the service interface[2] to do this, which is like providing the .service file for systemd.

The key difference is that it's built into the application[3] in Windows, not external like with systemd, which has pros and cons.

[1]: https://learn.microsoft.com/en-us/windows-server/administrat...

[2]: https://learn.microsoft.com/en-us/windows/win32/services/ser...

[3]: https://learn.microsoft.com/en-us/windows/win32/services/ser...

Looking at that page, it looks like syncthing chooses to not provide a Windows service. That is where 100% of the complexity is coming from. If they did provide a Windows service, then it would be as simple as opening the service manager, and setting the startup type from "manual" to "automatic".

It's not fair to blame Windows for the developers of an app not using its features. Similarly, if syncthing didn't bother to create a unit file on Linux, your example would no longer be a simple one liner. That wouldn't be systemd's fault though.

Coincidentally, Lennart works at MS. I don't know what he works on there though.

https://github.com/microsoft/sudo/issues/11

Interesting

Reserved

not blank!

We like to camp nice round number issues like this one, for future use.

Can you reuse GitHub issue numbers, or what could be their intention here?

You can edit the issue to be whatever you want later. But I’ve never seen anyone pre-reserve issue numbers like this.

We've actually done that for a few years on the Terminal repo. It's great for things like megathreads / scenarios / epics. For example, I can tell you off the top of my head that microsoft/terminal#8888 is for "quake mode", and #4000 is the extensions thread.

We even used to have a bot that would auto-camp anything that was a multiple of 1000 or 1111 :D

That's a rather fun hack for issue numbers. Of course, a more robust strategy would be to have a specialised short-link generator for special issues!

As they work at Microsoft, they all have aka.ms and can generate any short link they like.

But it won't work if another user talks about issue 1234, and you only have the short links in your head.

nice round number issues

But the number is 11? Is this Spinal Tap?

'All 1s' has history at MS...

We’re about to hit issue/pr 100,000, and I really want to land a neat PR on that number :)

Considering the way PowerShell commands go, I assume this will be:

  RunWithAllTheElevatedPermissionsPossible --YesEvenThose .\inthisfolder.folder\.

  grep : The term 'grep' is not recognized....

It's evident that you haven't used PowerShell. Almost all commands in PowerShell have short aliases. For instance, instead of typing 'Get-ChildItem', you can simply use 'gci', which stands for the first letters of each word. Unlike Bash and other shells, where you must learn various Domain-Specific Languages (DSLs) to handle XML, JSON, YAML, etc., PowerShell allows you to use its native language to work with any data type. This is because PowerShell operates on objects rather than plain text. Therefore, PowerShell is significantly more advanced than other shells.

lol

powershell stan detected

Yes. But if you Program, you do NOT want to use the aliases as they make your program hard to maintain over time. Little equivalent to banning short options and preferring long options in shell scripts. It makes the intent much clearer and your future you will thank you 6 months after the script was written when you have a bug to squash away...

Hiyo!

Yep, aliases help. Also, verbs are standardized. That example was a bit hyperbolic.

Most of my work is in Linux nowadays, but for me, jq, yq, and other text manipulation software and shell features in bash/zsh will always take a back seat to using the standard commands that ship with PowerShell. I wince every time I see a co-worker using a pipeline full of parse-and-pray greps and awks that is fancy af and amazing, but also, maybe not as nice or consistent as working with objects.

I will say though, you might say "PowerShell is more convenient in many scenarios," not that it's more advanced.

LOL

Sir, you're doing PowerShell wrong:

   Run-WithAllTheElevatedPermissionsPossible -YesEvenThose .\inthisfolder.folder\.

See, verb-noun. and single dash. because reasons?

Side note that I've always found interesting: sudo is almost entirely maintained by one dude: https://github.com/sudo-project/sudo/graphs/contributors

https://www.sudo.ws/about/history/#quest-sponsorship and apparently he's no longer being paid to work on it as of this week

not to completely stalk this guy, but for linkedin users, might be worth liking / sharing his looking for work post https://www.linkedin.com/posts/millert_after-over-13-years-w...

If he's in Nebraska, then it's literally https://xkcd.com/2347/

According to his website, he's been the maintainer for 30+ years.

Boulder,CO per his github

Wow. I thought sudo was maintained by kernel devs. Kudos to the maintainer tho

There's also https://www.memorysafety.org/initiative/sudo-su/

Sad that it's Windows 11 only. I can't upgrade. I have a normal, recent PC that I dual boot with Linux, and Microsoft wants me to keep Windows 10 in that constellation. Upgrading is prevented by a silly if statement, and there's nothing I can do. It's the first time a software vendor actively doesn't want me to to have their latest software, but it is what it is.

What do you mean? If it's the TPM requirement, Rufus can whip up a Win11 installer that bypasses that in like a minute.

Ventoy will also help them, there's absolutely something they could do.

You can also boot the normal installer, hit Shift+F10, run regedit, and set HKEY_LOCAL_MACHINE\SYSTEM\Setup\LabConfig\BypassTPMCheck to 1.

Unless there's official documentation that this is officially supported, hacks like these can stop working at any moment. For an unimportant machine, sure, use whatever third-party tool to bypass the installer you want. For a production machine, I don't think that's wise.

We're working on backporting it to Windows 10. For updates, you can follow https://github.com/microsoft/sudo/issues/2

There's always gsudo: https://github.com/gerardog/gsudo

This adds a factor of enshittification for NT, NT doesn't need 88 line PowerShell scripts, this "sudo for Windows" thing makes Windows seem like a teenager's high school project. Windows NT already has runas, let NT be NT and let POSIX have sudo/doas. Previously Microsoft hired the best of the best operating systems engineers in the USA who were from Digital and they proved to be people capable of making an operating system able to scale from MIPS to PowerPC/DEC Alpha/IA-32/amd64/Itanium with any combination of hardware and peripherics, now they're allowing random people to push 88 line scripts and calling it a day. Very few people in this world deserve the privilege of touching any Windows NT code and even more few people deserve the possibility of pushing things to the build lab of Windows NT 10/11 builds

Thanks? But sudo * isn't a 88 line PowerShell script, it's a 1800 LOC Rust binary * isn't a NT kernel feature, it's a usermode executable * was made by (in my opinion) a perfectly decent engineer. That may be thinking too highly of myself though.

I see you are one of the heads of sudo for Windows, now based on your comment I see sudo for Windows with non-so unhopeful eyes. The comment about 88 lines PS code is about sudo.ps1 on the repo, thanks for clarifying. I'd like if more consideration is taken over sudo for Windows, as the MSDN docs relate: sudo at the moment has a clear distinction with runas and you must be the one who chooses what's best, I can infere the intention is not replacing runas, but then there's two ways to the same goal and each one with its differences. It's a similar situation than it was with WMIC and WMI for PS, being this case as a longer-standing approach, WMIC is deprecated but you can still use it if you want, however WMI for PS has the same functionality as WMIC and still offering benefits over WMIC, ultimately WMIC will be removed from future Windows releases. I'd be less confusing if this route is planned for runas and sudo

you're too kind replying to this

They decided kernel-mode graphics isn't a terrible idea, though.

At the time that decision was made, it was the only way to get acceptable performance on typical computers on which NT was expected to run.

One day they'll replace the kernel with Linux and nobody notices

Unlikely. Windows is all about compatibility and that includes all the weird things accumulated in windows over the decades. There is not a real incentive to change this. Think of all the gamers, custom hardware like ATMs and commercial terminals that run on Windows. That’s a huge market.

Old windows software often runs better or only with Wine instead of recent windows versions. So if they want to keep their 'compatibility' long term, they have no choice but to to include (or worse, fork) wine.

Unless it touches hardware.

It depends. I would argue getting an old scanner or printer running with no current driver is definitely much easier on Linux as well. I am not into Windows enough to have any other examples :)

Linux + Wine

Here's hoping that "Windows 12" will be just a Window manager + Desktop running on Linux, with all existing bugs meticulously replicated to maintain backwards compatibility with Windows 95/7/8/10/11.

Stop dreaming. Won't happen. Windows is a purely additive effort. WSL is what happened, and when it couldn't do some things they built WSL2.

As another commenter pointed out regarding the integration of this new "sudo" and UAC prompts, it will probably be done in a new, separate, different tool, because this new, freshly released "sudo" will now have to remain bug-for-bug compatible for the next four decades.

WSL is what happened, and when it couldn't do some things they built WSL2.

I always wondered why it wasn't called WslEx.

If that ever happens, it'll bring Microsoft dependencies to the Linux ecosystem. In not sure that's a good thing anymore with the endless enshittification going on in Windows. Just imagine the poor distro maintainers constantly battling to disable spyware, ads, nag screens, and unwanted configuration changes caused by Microsoft packages. I feel sorry for them just by thinking about it.

To be fair that would still make windows instantly so much better if you could actually run a less weird desktop environment AND run all the vendor locked software.

And you then get sudo for free! With all the command parameters you know and love. Win-win.

When I was at Microsoft we did not use to consider UAC as a security boundary, since there were ways to bypass it. (I used to work on windows kernel security). I wonder how security team let this feature get shipped. Or perhaps now they consider UAC as a security boundary.

UAC still isn't a security boundary, but rather a defense-in-depth measure.

Shouldn't defense-in-depth be about putting multiple meaningful security measures in place?

Shallow is still a depth.

Whats the purpose of UAC then?

How can you bypass UAC set on the highest level?

So Microsoft implicitly admits DOS sucks and creates a PowerShell prompt.

Then Microsoft doubles down and introduces a better prompt called WSL - the Windows Subsystem for Linux because the Windows command prompt still sucks... and this is just a Ubuntu VM in Windows.

And now they implement Sudo?

Microsoft hasn't learned the first lesson of holes - when you find yourself in one, stop digging.

This is a really good illustration for why I hate using Microsoft products. They don't commit to one vision long-term. They build a bunch of competing visions, and all feel half-assed. From a user's perspective this means that if I want to perform some task I likely either have a clunky experience, or worse, I end up having to use multiple similar tools to do it.

Very bleh.

Reducing WSL, which can virtualize multiple Linux in parallel, including Linux GUI programs, use GPU and run Docker at near-native speed, to a mere prompt seems dishonest.

I wish they committed to implementing more of the POSIX standard instead. They only ever implemented an initial version, and then added tiny parts of it in incompatible ways.

This doesn't make any sense. PowerShell and WSL serve entirely different purposes. PowerShell is bash-but-better for Windows. WSL is a developer-oriented way of running Linux/Unix software on Windows.

I already use https://github.com/lukesampson/psutils which has a sudo.ps1, which I install via scoop (I know that's a mouthful, but I just install scoop and run `scoop install sudo`). I used it from powershell literally just before I opened this article (after copy-pasting a password, I copy some random text laying around in the browser, like "com", then run `sudo restart-service -name 'cbdhsvc*'` to clear the clipboard history -- does not clear the current value). There is a UAC prompt, but it's perfectly adequate for interactive work.

Mind that Windows has clipboard (win+v) history and you may've that enabled

Same here, and if you look at the output of whoami /priv you'll find that using luke's sudo provides exactly the same priviledge escalation as 'run as administrator' does

Scoop install gsudo is even better (still run as sudo).

Well, sudo for Windows has been a thing for, like, a few years now?... https://github.com/gerardog/gsudo

Not sure if this is the same thing, but this definitely should have shipped with the very first implementation of "oh, sure, you're an Administrator, but not really, since we're ignoring that bit" a.k.a. User Account Control.

That would have saved about a metric ton of misguided "here's how to turn off UAC" tutorials, but, ehm, yeah, anything to inject some life into the moribund Windows Insiders Program (the one where https://blogs.windows.com/windows-insider/ proudly headlines "What’s coming for the Windows Insider Program in 2023"), right?

gsudo is great! It's got a lot of features for power users, it's got a great community, and I can't recommend it highly enough. There's room here for us to be better together - Sudo for Windows can cover a number of in-box scenarios, with OS-side support for things like GPO, event logging, etc. But then for power users who need access to some of the wilder features of gsudo (running as TrustedInstaller?), that's always available too.

I would love it if I, as a lifelong Windows fanboy, could offer anything but a snarky reply to the author of a new OS feature. Yet, good luck with that and don't look at the headstones of those who came before you is all I can muster.

The blog post links gsudo right at the top:

If you’re looking for additional functionality that Sudo for Windows does not provide, check out Gerardo Grignoli’s gsudo which has a number of additional features and configuration options.

I've tried several times to code on Windows. It's nearly impossible for a person used to Unix based systems. Seems it's getting slightly better. Nice.

A chrome plated turd is, underneath the shiny veneer, still a turd.

But enough about MacOS.

sudo on windows has a different risk profile given the malware ecosystem and lack of educated/ trained users.

95% of linux users are developers who understand risk -- though are prone to mistakes

99% of windows users are casual consumers .

Let's keep this functionality narrowly accessible : restricted to developer mode and very formal consent. I suggest disabling it if it's unused for a few days

this will only rejuvenate the malware market.

There's still the UAC prompt which should help mitigate risk, plus it's locked behind developer settings.

that's good news

Windows should just run Linux. For apps that really need the Windows OS, use something akin to macOS parallels. I really like WSL of course, but would prefer an inverted paradigm.

The Windows kernel has a lot of features that Linux lacks. Dropping all those features would make a lot of people very angry, especially admins in big corporations.

It also has the most insane backwards compatibility.

I guess this is a thing on Windows now. However at the moment, it seems to be a very insecure thing. But hey it's early days... I predict they'll eventually get it right 125 patch Tuesdays from now.

https://fosstodon.org/@serghei@mastodon.social/1119009868252...

Happy to have the feedback! Most of those I've already fixed internally, there's just a 3-4 week delay between me checking in, and it flowing to Insiders.

For the other few things I missed: Very happy for the feedback! I've filed bugs and those'll be the first things I look at come Monday morning.

Yes! We all knew this was going to ripen into a massive security problem, however overnight was quicker than expected.

MS in a nutshell:

Ready, fire, aim!

Users:

"Immediately, there was a problem."

If it were anyone but windows this sentence wouldn't alarm me like it does:

Sudo for Windows is a new way for users to run elevated commands directly from an unelevated console session

Why is that?

In all honesty, I have the same reservations. If you look at the authz schemes between the different flavors of operating systems you see that the 'set-uid' concept is comparatively ancient, battle hardened and based on well understood mechanisms.

This new functionality in Windows looks complicated. There's an architectural picture that involves:

* Multiple processes

* Windows RPC (On the basis of RPC? DCOM?)

* Handle inheritance

* Process integrity(?)

* Token privileges(?)

When UAC was introduced, there was a slew of bugs in the underlying RPC mechanism. I wonder if it will be the same. Can't wait to take a look at this in the debugger :)

I also wonder if MSRC will consider this a "security boundary". Based on the fact that the text references process integrity(UAC), and that _is not_ a security boundary, I'm going to guess not. That means that this could potentially introduce bugs, but MSRC will not be handing out bounties to fix things. Which means that any bugs people find are less likely to be reported, and more likely to find their way into ransomware down the line.

Why is Inline not the default option?

There are security implications for running elevated processes connected to unelevated console/terminal windows. "New window" mode avoids those security concerns. A secure-by-default posture seemed prudent.

Just pointing out that this is a really good tweet by the co-creator of sudo: https://twitter.com/BobCoggeshall/status/1755681410596192604

I guess if we were on a conquest for universal adoption we can now say we've succeeded.. <pinches self>

sudo deltree c:\

Technically, powershell has a built-in alias of "rm" to the remove-item command. And Windows will happily accept / as the path separator. So you could do "sudo rm /" and it would be a legit command.

Can you draw the part of the diagram in the blog post based off of these sentences? https://devblogs.microsoft.com/commandline/introducing-sudo-...

In these configurations, sudo.exe will launch a new elevated process, an elevated sudo.exe process, and the original unelevated sudo.exe will establish an RPC connection with the new elevated process. In other words, information is passed from the unelevated sudo instance to the elevated one.

Yep, that's basically the entire diagram. The information that's passed is basically just the commandline, env vars, and a handle to the console of the unelevated sudo's console. Once it's got a handle to the console, the elevated sudo can spawn the target app attached to the original console, rather than a new one. Simple as that!

Ironic, didn't we find out they had patented sudo a decade ago?

https://arstechnica.com/information-technology/2009/11/micro...

The article you linked answers your (presumably rhetorical?) question: no, but they probably did patent PolicyKit.

Windows tries to improve the developer experience… why not call it wudo or something funny since devex on windows is obviously a joke.

I agree. Can pretty much generalize to Windows and not just Windows devex at this point. The OS is like a parody of itself.

Can someone detail the differences between this and runas plz?

runas doesn’t pass current directory, or environment (at least the last time I used runas on Windows 10). I vaguely recall that runas has a kinda low limit on command line length, too ( I’m possibly misremembering that one).

Do caffeinate next!

That reminds me, I have a half-written implementation here:

https://github.com/AustinWise/caffeinate

I've been using this (https://learn.microsoft.com/en-us/windows/powertoys/awake#co...) on my work computer for a few months and it works similarly to caffeinate.

Eh, nothing wrong with psexec.exe -i -s

Guess it's good to have more options though.

psexec -i -s is more than sudo, it runs as SYSTEM. Basically with kernel level permissions, that is above admin.

Still, doesn’t prevent antimalware software from blocking you if you try something naughty.

I wrote a Node.js module that implemented similar feature years ago. https://github.com/atom-archive/node-runas (An updated fork can be found at https://www.npmjs.com/package/runas-redux)

This is good, but runas already exists. Its interface is shit. Improve it to make it not shit please. Don't hijack the name of an existing command unless you're going to re-implement its interface 100% compatibly.

This is like when PowerShell hijacked curl all over again...

How do you wax lyrical for an entire article about the excellently engaging ergonomics of sudo and not mention Linux/Unix family of OSes

… Checking the date… Nope it’s probably real (and makes sense!)

sudo cmd.exe

the new "sudo bash"

Scoop provides https://github.com/lukesampson/psutils, which works really well, I am sure there are a million things people will tell me I am missing.

Is it April 1st already?

what about "runas" :-) or this is considered psuedo-sudo?

reinventing Unix, poorly.

Get over it, Microsoft and migrate to a Unix kernel ;)

One of the most important aspects of ‘sudo’ is that it takes the password of the user who started it, not the admin password. Will this ‘sudo’ work like that, or does it need the user to know an administrator password? If it needs an admin password, it shouldn’t be called ‘sudo’ (it would be an analog of ‘su’)

There's already a tool out there that works just fine: https://github.com/gerardog/gsudo

sudo make me a sandwich!

After long 40+ years Windows has caught up.

If you'd like to use sudo, it's available in Linux.

I just hope Windows sudo is not as braindead as PowerShell's wget!

"Those who do not understand Unix are condemned to reinvent it, poorly." -Henry Spencer

Good. Although "elevate" from Nirsoft[0] generally worked well for me, it's nice to have something more integrated into the system.

[0] http://nircmd.nirsoft.net/elevate.html

If anyone on older Windows version, `elevate` tool is similar. Also if it isn't the normal sudo command maybe call it something else as well.

While this looks more secure than the original, I don't think modern operating systems should be investing resources into making privilege escalation easier for users to do. Considering UAC already exists it's not like the additon of sudo is much worse to include so overall it may be better, but I feel investing resources to get rid of the need of users needing to elevate things would be time better spent.

missed opportunity to call it suwoop

Is this going to be a fully proper implementation with a sudoers config such that something like

    sudo c:\some\path\to\normally_needs_elevation_to_function.exe

will work for my user in my current desktop session without an elevation prompt?

hmmm, so I no longer need to right click on cmd and run as administrator?

The new command is named “sudo” because customer feedback and because MUSCLE MEMORY:

I hear you! We thought about some of the options you’re calling out here. A lot of customers voiced having the muscle memory of doing similar flows on various operating systems was more important to them and that’s where we landed. I totally understand your perspective and I do really appreciate the feedback. I’m always trying to learn from people like you so I can help to build things that will make your life better.

From https://devblogs.microsoft.com/commandline/introducing-sudo-...

Good news.

But I'm also bracing for millions of windows users that will now be able to sudo pip install.

Can't wait for new malware to sudo-up the calculator && bitsadmin.