Sudo for Windows
devblogs.microsoft.com
devblogs.microsoft.com
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!
What issues are your customers having that they need profesional help to upgrade to a new Windows OS?
YEs I was asking seriously. You still haven't explained what those challenges could be. All you do is mock people for their genuine questions without providing any actual answers/information to back up your vage statements.
>You've clearly never worked in any kind of customer support position
Then if that's clear for you I haven't never done that, why would you not understand I was being serious? Why are you being disingenuous here? Or you just enjoy being a troll?
> because businesses and individuals need all kinds of help with a transition like that.
Mate, 12 year-olds in my developing country can run Windows 11 updates/installs for you, including installing pirated licenses and cracks for you if you pay them 5 bucks.
What could be so complicated that the internal IT of a company can't figure out the transition from Windows 10 to 11 that they need to pay outside help for that? Especially that backwards compatibility is one of Microsoft's fortes to make life easier for admins and convince companies to stay in their ecosystem.
Many small and medium companies don't have any internal IT. Maybe the original parent commentor works for an MSP / outsourced IT services provider / as an IT consultant.
> "What could be so complicated that"
Windows 11 has hardware requirements that Windows 10 didn't, their equipment may need to be reviewed/audited or refreshed - planned, budgetted, quoted, ordered, received, checked, configured, user data migrated over for dozens of devices. Business customers need to buy Windows Pro not Windows Home - and need enough IT experience to know that, non-technical companies may have bought some Windows 11, had problems, and needed to call someone for help. A company might have some internal IT who could do it, but are busy with other projects and don't have time to plan and execute an upgrade. Windows 11 comes with new Group Policy templates which need importing to a Windows domain and configuring - and may need reviewing or auditing for regulatory compliance to see what needs setting up and the parent commentor is some kind of compliance person helping with paperwork instead of a technical person. A company might take an upgrade to Windows 11 as a time to change other things like a move to Microsoft Cloud Services (OneDrive, Microsoft account for login) and each user needs to be given a new laptop and have all their settings moved over. A company might have specialist software from vendors who aren't very progressive - e.g. optician's software which manages retina scanning cameras - and needs lots of time consuming hand holding with the vendor support line before the vendor will agree to the move, even if it would in principle work fine. Regardless of technical issues, the upgrade could take an hour or two per machine, over dozens or hundreds of machines, that's either a big interruption which needs planning (staged rollout for different departments, say) or needs some automated way to deploy it which needs setting up, testing, and checking on, and may just hire some temporary contractors for more people to do that. There may be users who could do it, but won't because it isn't their job, or aren't allowed to by their manager or union so it isn't their responsibility if it goes wrong.
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.
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"...
(See the transcript of Security Now 958 for recent details.)
Even continually sticking to old design patterns causes issues in development and deployment. Big name companies do not trust applications running on hosted Windows because of their current business practices. Microsoft does not even have a means to provided ease of deployment for air-gap system. This is the only way some big business will let products hosted on Windows to be in their facilities.
Windows as become more problematic for me because of all the layers of security that need to be applied for companies to trust Windows. This causes issues such as having to stop typing because Visual Studios or VSCode cannot process key strokes in real time.
Localization translation text standard still does not allow for containing singular and plural in the same key. Translations should be easily to update so the client can improve wording on the fly. Microsoft still recommends using resx and compiling a DLL.
.....
This is a big issue for me. I'm stuck using Windows for work, and it runs like an absolute dog even on good hardware.
Why to a crawl? Well, I've witnessed multiple antivirus products go bezerk on your dev folder if you compile C++. Turning them off for this folder increased performance by a factor, which is what's typically done and completely subverts the purpose of these products. Also, I witnessed a certain product with a bird of prey that would run for hours and then just crash on a directory with a few million files.
This combination of sub-par quality of "security" products and performative deployment of endpoint security is a bane, at least for me as an enterprise software developer. I don't see Microsoft being primarily at fault there.
Powershell is a super neat language though.... especially if the Microsoft team that manages it would work more with the team that does more for SMEs and not just DevOps. The overwhelming majority of windows users doing regular business work have to deal with crufty stuff like VBA or over engineered stuff like C#. I was really hopeful for Powershell, but it seems like it's almost entirely to serve IT administrators or software developers. I wish that very capable team would do things like add a fairly simple GUI DSL or form designer with the tool. I know it can hook into WinForms, but that's a lot of effort and requires more C# background. There are probably millions of business analysts that would love to build little simple GUI apps without investing weeks of effort. The current approach is to just use Python, but that has it's own bag of problems for those that can do a little coding, but aren't full time developers. It just seems weird that Microsoft never invested in a language for SMEs that would integrate well with the OS and Microsoft apps and tooling.
Give me C# over PS any day.
$value = 10
if ($value -eq 10) {
Write-Host "Value is exactly 10."
}The weird part of PS is the piping, which doesn't always do what you think it should as everything is an object instead of text.
value="1 -o 1"
if [ $value -eq 10 ]; then
echo "Value is exactly 10."
fi
Also, why does the documentation[0] talk about statements returning values? I've never seen the terminology used that way before. Usually expressions evaluate to a value and statements can consist of an single expression.
[0] https://learn.microsoft.com/en-us/powershell/module/microsof...
They could use `==` for equality but then what symbols would -ceq and -ieq be?
What symbols or what else would work for `-match` and `-in` and `-cmatch`?
If they were just `eq` or did use `==` how would that work for when they are actually options to a cmdlet such as `| where-object -eq $x` ?
I also don't even like their verb-noun philosophy because it's impossible to figure out what the commands are and there are so many. It's still all objects and methods underneath but you can't auto-complete anything.
Handwaving away decades of muscle memory and expectations for > and | seems bad, but those are the easy cases, and you've avoided dealing with the operators which are not symbols and the case sensitive/insensitive variants of common operators. What do you suggest for syntax instead which handles all, or most, of the cases PowerShell handles?
We have had "decades of programming language development" but I'm not aware of any which do what PowerShell does. I haven't spent any time on OilShell or NuShell or other Unix-shell-modernised systems, but Python syntax and behaviour does not make for a good shell, nor do any other programming-language-with-REPL that I've used. What language are you thinking of which makes a good compromise of both shell and pipeline and programming language, which would also work in the Windows world where things aren't text (PowerShell design priority)?
> "I also don't even like their verb-noun philosophy because it's impossible to figure out what the commands are and there are so many."
On a computer system where many thousands of things are possible, specifying what to do by command line is going to require typing one thing for every option you need to specify. Whether that's in the command name, in the command options, in the arguments to the options, or externalised in some ENV variable or /sys/ namespace or some /proc/ data source or some /etc or .dotfile config option, or hiding in some JSON structure, it's only shuffling the complexity around. At least with many commands they are organised into modules, searchable, and can have associated help.
> "you can't auto-complete anything."
*date*<tab> cycles through all commands with 'date' in their name. Cmdlets and binaries and functions.
hyper-v\*failover*<tab> cycles through all cmdlets in the Hyper-V module which have 'failover' in their name.
Get-Command -Noun VHD searches for commands with VHD as the noun part of Verb-Noun.
Get-Command -Parameter VlanId searches for commands which take -VlanId as a parameter (e.g. Hyper-V\Set-VMNetworkAdapterVlan).
Also winget does not have python 3.12 which was released 4 months ago.
And you don't have to use --id - you can do `winget install 7zip` etc in cases where there's no ambiguity.
I was able to find the 7zip page by googling for it: https://winget.run/pkg/7zip/7zip
But as with Python the default suggestion is `winget install -e --id 7zip.7zip`. If I can just do `winget install 7zip`, why can't they show that command? Why is the complicated way the default and the simple, intuitive method optional and not easily discoverable?
There's lots of room for improvement.
Those sites give you the command line exact match (-e) --id as a safety precaution so that you install exactly what you were looking at on that website and not a fake or similarly named but different installer or a different version than what you expected.
The complicated way is optional, you are using two different options: -e and --id. The CLI's default is actually sloppier when you don't use those two options in that way.
It seems easily discoverable from `winget --help` to me. But I tend to use `winget search` rather than websites, so maybe I'm just more familiar with it.
For us developers, the changes in Windows to support WSL2 weren't really an enhancement of Windows, it's now just a really complicated way to run Ubuntu. As in, Windows 11 is the biggest Linux bootloader in history.
sudo for Windows...can't even see a use for it any more.
WSL 1 is allowed luckily, but it's kinda meh
Does this elevate within your own account token (i.e. will not work for non-Administrator users), or does it actually switch user (e.g. to LOCAL SYSTEM)?
Allow $PARENT_PROCESS_NAME to run $COMMAND with administrator rights.
So if you would enter the following in cmd.exe:
sudo notepad.exe ...
Allow Command Processor Shell to run notepad.exe ... with administrator rights.
Why?
I'm not critical. I don't have enough knowledge on the situation to share criticism on the topic yet.
I could have added "Could you expand on this?" to clarify my intent.
It's a tricky feature to ship, cause it is ultimately something that can be used as an escalation of privilege vector. Like, that's the entire idea. And there are a lot of people who (very rightly) get the ick when you say "we want to add this thing which can be used as an EoP to the OS image".
So, it's kinda hard to believe that after four years of thinking it was impossible, we actually managed to get it out the door.
Great work making this happen!
Thanks for taking the time to answer, very appreciated! You must be happy to have been wrong, ah ah.
The biggest visibility into this issue is software installers, which regularly offer to launch the freshly installed program for the user's convenience...with the same elevated permissions the installer itself uses.
[0]: according to this SO answer, runas still runs the process with high integrity: https://stackoverflow.com/questions/20218076/batch-file-drop...
me: "Why should we be glad that Microsoft is not functional enough to make a decent product...?"
HN: flag!
Can't you call the target program directly? There must be a way, because explorer.exe is not elevated, and when you right click a program and choose "Run as administrator" you get a pop-up for the target .exe, not for Explorer.
> Enable Sudo
> Enables the sudo command
If I were a scammer I could make up an acronym or something that sudo means and trick someone into turning this on because the toggle doesn't actually describe what it is so I can just weave my own narrative.
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..?
It's hard to imagine a company that size would name it so deliberately without realizing it would cause confusion in search engine results and such.
A good faith assumption would be they wanted to make Windows more familiar to users of both but it also means that Windows will get mentioned in more Linux results over time to disambiguate it.
same microsoft as where I'm from?
embrace (copy sudo), extend (add incompatible options), extinguish
Yes, we know. Internet Explorer, yada yada. Beyond the ridiculousness of the notion of sudo specifically being a target for MS, the notion that MS, or any company of its size, is THAT single-minded, is absurd.
While I understand picking a familiar name, sudo is certainly not the only player, there's also doas. This shows people can adapt to another name and another name would have seemed more appropriate.
edit: whoops, it was already mentioned in this thread [3]
[1] https://daniel.haxx.se/blog/2016/08/19/removing-the-powershe...
The fact that doas has far fewer users, and examples everywhere show `sudo xyz` as the way to run xyz as root, shows that people do not adapt to a different name.
Microsoft has been trying, for years, to get developers to use Windows systems. This is another good step towards doing so.
The answer isn't to use a different name; the answer is to actually support most of the sudo interface.
But that said, there's a subset of the sudo interface that would cover the majority of what most people need on a regular basis:
-H (change home directory)
-i (act like a login shell, which may not be meaningful on Windows but could at least be ignored for compatibility)
-E (preserve the environment)
-u (set the user to something other than root)
-g (set the group)
-s (just run a shell)
The answer is to do either.
i.e. the complaint about using the name while offering a different, incompatible interface is valid.
I do think it was correct to use the name, though, which means they should be more compatible.
Of course, it being an issue is an opinion (of mine), see my daniel.haxx.se link from my other comment next to yours for a motivation of this opinion.
Now "sudo" is not a very Windows-y name for this utility but it has the advantage of being self-descriptive by those most likely to use it. It's sudo... for Windows. You don't have to explain it further.
The command line namespace is flat and there are only so many letter combinations, the idea that an OS shouldn't reuse a command name from a different OS is pretty limiting.
Good point, the unlikeliness to ever run the real sudo on Windows makes it less an issue. Though doesn't remove it completely. You could for instance imagine a bash script (which you can run on Windows, since you can install Bash there) trying to use sudo if present, or something else, and fail because sudo is present but doesn't have the expected features. In shell land, the name of a command is almost an implicit contract.
> The command line namespace is flat and there are only so many letter combinations, the idea that an OS shouldn't reuse a command name from a different OS is pretty limiting.
In practice:
- Programs are mostly cross platform so many "commands" can work on different OS. Which makes the command line namespace quite shared between OSes
- I've not seen many clashes. I can certainly remember of one: the Chromium browser and the Chromium B.S.U game. It was unintentional. The "sudo" one is. You can certainly avoid it.
At a basic level, I’d wager a vast majority of sudo’s usage is very basic, “run this command as admin”. If it can do that out of the box, it solves for a vast majority of users and they don’t have to learn some kind of new cmdlet to be able to do it.
I also can't imagine a different name to cause such a training issue. We are speaking about people who learned using the terminal on Unix and are using it on Windows. They are likely at ease with computers. If they are confused by a name change, I can't imagine how confused they could be at the first difference they encounter. The same name might as well cause more training issues. I'm not convinced.
Linux users can experience this now by using sed on macOS
> it does the same function which is to elevate a unprivileged command
That's only one of the use cases of Sudo. Here's a description of Sudo from the official manual [1]:
> sudo, sudoedit — execute a command as another user
Sudo for Windows can't do that. It's mentioned in its FAQ:
> the sudo command on Windows does not support running programs as other users
Sudo for Windows is like a cat command that can't concatenate files or a touch command that doesn't update timestamps.
Oh, that's a good counter-example to your own point: 99% of people who use cat don't care about this functionality.
cat *.txt
Same goes for sudo. If you're going to claim that a whopping 99% of users don't use the CLI options or /etc/sudoers, you'd need solid proof. Because a simple search shows otherwise:
https://grep.app/search?q=sudo%20-®exp=true
This Sudo for Windows behaves nothing like the actual sudo. It doesn't even achieve the original's stated purpose.
Also considering that search results for anything involving Windows tends to be riddled with spams and outright scams, this will negatively affect non-Windows users searching for sudo as well.
So again, this naming conflict is unfortunate.
That's an astonishing claim to make without evidence. I don't see "cat *" being used anywhere. In fact, I've just ran search for usage of "cat" over the repository of shell scripts that are used for the various packaging and deployment tasks in my company (and we have to deploy a lot of stuff, written in different programming languages, and every team packages their stuff into their docker containers in their own way but it's all still documented in this repo) and every single use of cat is either
a) reading data into a variable "VAR=$(cat file_with_data)";
b) writing inline data from script into a file "cat >>$TARGET_FILE <<EOF ... EOF";
c) an entirely reasonable use of cat "cat file | utility_that_accepts_filenames_too", sometimes even "cat file | utility".
None of them take a pattern or more than one file.
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.
OpenSSL, Curl, Git, Linux, Gettext, NodeJS, zstd, GCC, FFmpeg, OpenJDK, Pyenv
I think users, upstream developers, and downstream packagers of these software will all be upset if cat ceased to concatenate.
Example:
https://sourcegraph.com/search?q=context:global+repo:%5Egith...
UPD: And lots of people use "cat file1 >>output; cat file2 >>output" for concatenation anyhow [0]. Apparently shell already can concatenate things well enough, so cat should do one thing and do it we;l: dump a single file contents to stdout /s.
That's because it's a regex search and not relevant to the point at all. What matters is that people use widely advertised features of a popular tool, including sudo and cat. Especially if that feature is the single stated purpose of the tool.
Taking a name of a widely used tool and slapping it on something that doesn't even do what the original was made for isn't a nice thing to do. I don't get why that's controversial to anyone.
> so cat should do one thing
That one thing is con-"cat"-enating files, so to speak. Why should it become something different just to make the name Sudo for Windows appear somehow less misleading?
Also,
rm out.txt
for f in *.log; do cat "$f" >> out.txt; done
{ for f in *.log; do cat "$f"; done; } | less
This is off topic, but the Git devs were correct in doing `cat pine patch1 | git am`, since the test in question is
test_expect_success 'am takes patches from a Pine mailbox'
cat patch1 >> pine
git am pine
Plus it means I don't have to leave the comfort of Tabby.
powershell.exe -executionpolicy unrestricted -file ./setup_windows.ps1 -InstallPSWindowsUpdate -UpdateWindows -UpdateChocoPackages
powershell.exe -executionpolicy unrestricted -file ./setup_windows.ps1 -InstallPSWindowsUpdate -UpdateWindows -UpdateChocoPackages
powershell -ex bypass -f ./setup_windows.ps1 -I -UpdateW -UpdateC
If the elevation prompt would show the elevated executable and not the wrapper, that would be news...
Just scrolling through the documentation [1] gives some idea. Examples in the end may surprise the reader with the variety of capabilities.
[1]: https://www.man7.org/linux/man-pages/man5/sudoers.5.html
Sudo is widely understood to refer to a program which allows specific users to run specific privileged commands.
Or does runas work differently than I thought?
(Also, if UAC settings are turned down, that might mean the UAC prompt isn't on the secure desktop, and any malware can thus trivially elevate itself if your everyday account is an admin... etc.)
But the base "sudo" case where you have an account that supports UAC elevation (you are your own administrator) runas definitely supports as the CLI way to invoke UAC prompts for your own account, not just other administrator accounts. (Using the /trustlevel flag accordingly, as I recall.)
https://learn.microsoft.com/en-us/windows/sudo/#how-is-sudo-...
https://www.reddit.com/r/linuxmasterrace/comments/u4xeoy/in_...
I am not asking questions about sudo to someone assuming sudo is specifically Linux software.
When coming up with your sudo what were your inspirations and what does sudo do that you decided you wanted to avoid?
Probably some MS server =|
Alternatively, a stern yet extremely polite mail from Raymond Chen asking what you were actually trying to accomplish.
Every little bit of friction removed is a good thing.
Linux is open source and free, Apple develop an OS that sells specific hardware, and historically Windows has sold the software for generic hardware. Windows is unlikely to become a better Linux than Linux. Where is Microsoft's new business model going?
Historically Office was a money maker, but Office online is a shambles and many users interact with Office via this interface - I see Office slowly dying in favour of open source options. I see Windows licenses being sold less and less in the future. Microsoft Lens is essentially buried at this point. There are the Surface laptops/tablets which are good but not special. Dedicated games console hardware will likely become less attractive as they slowly become glorified desktop PCs.
I don't see Microsoft with big user shares in the software or hardware industries? There were a few good purchases such as Minecraft, GitHub (+), etc [1]. Is there something I'm missing?
[1] https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitio...
(+) GitHub's new security model is outright hostile - to the point I no longer want to use it.
"Microsoft revenue was $198 billion in 2022, up $30.2bn (+18%) from a year earlier. When we do a breakdown by product streams, the largest source of Microsoft’s revenue was Office, with $44.9 billion (23% of the total). Just behind in the second place was Azure with $44bn of revenue (22% of total)." - https://www.kamilfranek.com/microsoft-revenue-breakdown/
Office alone increasing by $5Bn revenue in a year, increasing by $24Bn in ~3 years, being the largest chunk of revenue of the most valuable market-cap company on the planet, that's what counts as "slowly dying"??
It's possible this sudo could have been implement as yet more clunky flags to runas, but it seems like making it a separate tool has benefits: off by default, whereas runas is a nearly always-on required built-in; more importantly a nicer less clunky syntax.
and what's the point of switching when gsudo basically does the same?
exactly how is 'sudo for windows' different than the existing model in windows 10 where privilege elevation is a popup window and you click through it? arguably the current model is just sudo with nopasswd.
how do you reconcile the idea that your effort --without principled reform of the windows security model at a fundamental level-- is just cargo-culting a more successful projects security model?
'Start-Process powershell -Verb runAs' is the same or different than this?
Thanks for caring about security and trying to make things better. its hard, thankless and frustrating (and thats just the windows part ;))
Sorry, this has been lacking for so long that you know... Late to the party.
Any particular reason the source code for sudo.exe wasn’t able to be open sourced along with the announcement of this feature?
Reminds me of when PowerShell decided to have "wget" and "curl" cmdlets that didn't have any of the advanced features of the originals. Naively it sounds helpful. But it introduces confusion.
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?
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
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").
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.
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'.
According to his website, he's been the maintainer for 30+ years.
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?
> 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.
RunWithAllTheElevatedPermissionsPossible --YesEvenThose .\inthisfolder.folder\.
grep : The term 'grep' is not recognized....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.
Run-WithAllTheElevatedPermissionsPossible -YesEvenThose .\inthisfolder.folder\.
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?
We even used to have a bot that would auto-camp anything that was a multiple of 1000 or 1111 :D
But it won't work if another user talks about issue 1234, and you only have the short links in your head.
But the number is 11? Is this Spinal Tap?
https://fosstodon.org/@serghei@mastodon.social/1119009868252...
MS in a nutshell:
Ready, fire, aim!
Users:
"Immediately, there was a problem."
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.
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.
I always wondered why it wasn't called WslEx.
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.
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
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 logged in as a standard user, UAC prompts you for new username and password to authenticate and authorize the privileged operation.
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.
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.
And on UNIX, I have worked plenty of times where no one gets root on the shared development servers, other than IT folks themselves.
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.
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.
Only every security audit under the sun. If you work for a sufficiently large organization subject to industrial or governmental regulation, or even carry particular insurance policies, third party audits will flag these practices as liabilities, because its boilerplate recommendation for how a managed windows environment is deployed.
You may work for a large organization where you get local windows admin. Exceptions can be made if a good story can be told about compensating systemic and detective controls that sufficiently mitigate the risk.
However I promise you that someone in that organization closer to security strategy and compliance gets grief over the posture at least annually. Those people shelter you from worrying more about it.
UAC is safe from that.
Well, now we can sudo them.
Seems like it's not an alias.
[1] https://learn.microsoft.com/en-us/windows/sudo/#how-is-sudo-...
sudo c:\some\path\to\normally_needs_elevation_to_function.exe
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.
Very bleh.
https://arstechnica.com/information-technology/2009/11/micro...
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.
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.
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.
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.
The point of sudo is not which password is used, whatsoever.
It's a convenience thing.
This looks like one of those KPI fulfilling projects.
Or forgot to Run As and opened a non-elevated terminal by accident?
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."
https://learn.microsoft.com/en-us/previous-versions/windows/...
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.
And then maybe creating alias to sudo in PowerShell like it does for other things.
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'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.
https://learn.microsoft.com/en-us/windows/sudo/#how-is-sudo-...
> 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?
> Runas /user:administrator "application.exe"
Think this might be why it's not very well known compared to 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.
That reminds me, I have a half-written implementation here:
> Sudo for Windows is a new way for users to run elevated commands directly from an unelevated console session
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.
Now that isn't necessarily true for Windows running in the cloud. Drivers don't matter as much there.
They don’t have to adopt it, they will probably fork it.
It's going to be more compatible with Word than Word is?
Reminds me of a specific thought experiment with a boat.
(For today’s 10000 (https://xkcd.com/1053/))
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.
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
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.
because it didn't work
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?
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
https://www.microsoft.com/en-us/sql-server/blog/2016/12/16/s...
But I'm also bracing for millions of windows users that will now be able to sudo pip install.
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.
And before that, some people might remember https://en.wikipedia.org/wiki/Virtual_PC#Windows_XP_Mode.
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.
> 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.
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...
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 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.
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.
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...
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.
https://learn.microsoft.com/en-us/windows-server/administrat...
myservice.exe /install
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...
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-...
* asadmin
* admindo
* adminrun
* admrun
* elevate
* privelevThis is like when PowerShell hijacked curl all over again...
Guess it's good to have more options though.
Still, doesn’t prevent antimalware software from blocking you if you try something naughty.
the new "sudo bash"
Everyone knows, if you can C colon, your running a M$ product...
I run Windows as my primary development environment because it's better. Linux and other OSes run in VMs.
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?
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.
Linux is just as much of a Unix as any OS in actual widespread use.