Microsoft kondigt sudo voor Windows aan

Microsoft heeft een sudofunctie voor Windows 11 aangekondigd. Net als op Linux kunnen gebruikers daarmee in een terminal commando's met adminrechten uitvoeren. Tot nu toe is daarvoor een apart terminalvenster met beheerrechten nodig onder Windows.

Microsoft maakt het project opensource en zet het op GitHub, Microsoft gaat de functie eerst uitbrengen in de Insiders-testversie van Windows 11. Gebruikers moeten de functie eerst aanzetten in de instellingen. Daarna opent het commando 'sudo' standaard een nieuwe console met adminrechten, nadat gebruikers dat via een dialoogvenster hebben goedgekeurd. Het kan ook openen in het huidige venster zonder mogelijkheid van verdere commando's of met mogelijkheid voor meer commando's.

Omdat de aankondiging offline is, is onbekend wanneer de functie in de Insiders-versie komt. Het gaat om Insiders Preview 26052. Daarna gaat Microsoft in de 'komende maanden' verder werken aan de functie. Sudo komt ook in Windows Server, bleek eerder deze week.

Update 20.22 uur: Dit nieuwsbericht bevatte de informatie dat de aankondiging online was geweest, maar weer offline was gehaald. Inmiddels is de aankondiging weer online.

Windows sudo

Reacties (77)

[AntBond]

Voor de mensen die niet kunnen wachten of nog op Windows 10 zitten: https://gerardog.github.io/gsudo/. Staat ook op Chocolatey.

[renecl]

Wat is het voordeel hiervan?

[dutchgio]

Het werkt (deels) hetzelfde als op Linux, en geen onnodige muisklikken om een nieuw terminal venster te openen en admin rechten toe te staan?

[Noxious]

Dit is ook geen nieuwe functie. Waarschijnlijk is het 'onder de motorkap' gewoon een alias naar:

PS> Start-Process <command> -Verb runAs

Of afgekort:

PS> saps <command> -v runAs

Maar door 'sudo' te gebruiken, worden cross-platform scripts en applicaties weer een stukje meer compatibel.

[Rembert]

Zelfs na dik 20 jaar kan ik niet wennen aan PowerShell (voorheen Microsoft Shell). Ik gebruik het hooguit om een Entra omgeving te beheren vanuit macOS. Elke keer sta ik verbaasd over de lange commando-regels. Maar goed, zo zal ik 40 jaar geleden ook wel naar bash etc. hebben gekeken.

[CAPSLOCK2000]

Zelfs na dik 20 jaar kan ik niet wennen aan PowerShell (voorheen Microsoft Shell). Ik gebruik het hooguit om een Entra omgeving te beheren vanuit macOS. Elke keer sta ik verbaasd over de lange commando-regels. Maar goed, zo zal ik 40 jaar geleden ook wel naar bash etc. hebben gekeken.

Ik denk het niet, bash en de unix cli volgen een heel andere filosofie en design. Of als ik eerlijk ben, een gebrek aan design, het is meer 'survival of the fittest'. Door de jaren heen hebben tientallen varianten van allerlei tools bestaan die gedurende vele jaren zijn fijngeslepen een doorgevolueerd. Daardoor zijn heel veel van die tools enorm krachtig en helemaal geoptimaliseerd voor een bepaalde taak. Deel van die optimalisatie is dat deze tools zijn gericht op interactief gebruik op de commandline en scripting.
Het is echter niet zonder keerzijde en die is dat al die tools uniek zijn en allemaal net wat anders werken, er is geen centraal design dat ze allemaal volgen. Door de jaren heen is wel geprobeerd om een en ander een beetje recht te trekken nooit ten koste van backwards-compatiblity en altijd met het oog op de interactieve gebruiker.

Daardoor zijn commando's heel kort en cryptisch met defaults gericht op typische CLI werk door ervaren gebruikers. De belangrijkste commando's zijn typisch 2-4 karakters lang en de meeste gebruikte opties gebruiken zijn 1 karakter lang.

Powershell is veel beter gestructureerd en is bewust ontworpen als totaalpakket maar geeft veel minder prioriteit aan iinteractief gebruik. PS kiest liever voor een lang maar duidelijk commando dat relatief eenvoudig te begrijpen is, ook als je het nooit eerder hebt gezien. Dat maakt het makkelijker te programmeren en te debuggen.
De keerzijde daarvan is dat al snel omslachtig voelt in vergelijking met de Unix shell die gemaakt is om snel en makkelijk in te tikken.

[DJ Henk]

Ik denk het niet, bash en de unix cli volgen een heel andere filosofie en design. Of als ik eerlijk ben, een gebrek aan design, het is meer 'survival of the fittest'. Door de jaren heen hebben tientallen varianten van allerlei tools bestaan die gedurende vele jaren zijn fijngeslepen een doorgevolueerd. Daardoor zijn heel veel van die tools enorm krachtig en helemaal geoptimaliseerd voor een bepaalde taak.

Zo ging het niet helemaal. Er was wel een soort survival of the fittest, maar dat een commando helemaal geoptimaliseerd is voor een bepaalde taak is juist de filosofie van Unix. Het idee was dat je beter een programma kunt habben wat een ding heel goed doet, dan een programma dat veel dingen maar matig kan doen.

Het briljante idee was toen om die programma's-met-een-enkel-doel makkelijk aan elkaar te kunnen knopen met behulp van pipes. Ofwel, je kunt de uitvoer van het ene commando gebruiken als invoer van het volgende commando en zo kun je functionaliteiten aan elkaar knopen en uiteindelijk elke taak volbrengen met een set commando's die helemaal geoptimaliseerd zijn.

Voor tweakers die in het weekend zin hebben op wat nostalgische video's te kijken: hier legt Brian Kernighan het heel duidelijk uit in een filmpje uit 1982

Daardoor zijn commando's heel kort en cryptisch met defaults gericht op typische CLI werk door ervaren gebruikers. De belangrijkste commando's zijn typisch 2-4 karakters lang en de meeste gebruikte opties gebruiken zijn 1 karakter lang.

Hoewel het voor zover ik weet geen officiele standaard is, hebben de meeste commando's zowel korte als lange varianten van dezelfde optie. Bijvoorbeeld "ls -a" en "ls --all", wat allebei hetzelfde doet. Het idee erachter is dat je de korte gebruikt als je zelf aan het typen bent en vooral snel wilt zijn. De lange variant gebruik je in scripts, zodat het duidelijker is wat het commando doet als je er later nog eens naar kijkt,

[Reactie gewijzigd door DJ Henk op 22 juli 2024 15:04]

[CAPSLOCK2000]

Zo ging het niet helemaal. Er was wel een soort survival of the fittest, maar dat een commando helemaal geoptimaliseerd is voor een bepaalde taak is juist de filosofie van Unix. Het idee was dat je beter een programma kunt habben wat een ding heel goed doet, dan een programma dat veel dingen maar matig kan doen.

Het punt dat ik probeer te maken is dat veel van die tools hun eigen pad hebben gevolgd zonder rekening te houden met wat andere tools doen (of vooral, hoe de interface werkt). Ze zijn individueel geoptimaliseerd voor hun taak. Dat maakt die commando's heel krachtig maar het gaat wel ten koste van de onderlinge consistentie. Alle tools zijn geoptimaliseerd voor hun eigen taak maar ze zijn niet geoptimaliseerd om samen een consistent geheel te vormen.

Zo worden de korte opties door ieder commando anders ingevuld. Voorbeeld:

• ls -c => sort by ctime
• grep -c => count matching lines
• sort -c => check for sorted output
• cut -c => select only these characters

Dit zijn veelgebruikte commando's en ze geven allemaal een andere invullig aan '-c'.
Als je die tools goed kent dan weet je wat die tool met -c bedoelt. De ervaren gebruiker weet of het nu voor "count" staat of voor "characters" of voor "check". Voor de nieuwe gebruiker is het echter totaal onverspelbaar en verwarrend dat die betekenis zoveel kan verschillen. Met de lange opties gaat het beter maar die zijn omslachtigert om in te tikken.

Het kost tijd om al die commando's en hun opties te leren. Als je er veel gebruik van maakt betaalt dat zichzelf terug maar het maakt het wel minder toegankelijk. Wanneer je zo'n hele omgeving nieuw ontwerpt zou je waarschijnlijk kiezen om opties overal hetzelfde te laten werken zodat je iedere optie maar één keer hoeft te leren zonder ambiguiteit, zoals powershell heeft gedaan (of in ieder geval geprobeerd). Het gevolg daarvan is dan wel dat tools minder geoptimaliseerd zijn voor één specifieke taak maar ook een beetje rekening houden met alle andere gereedschappen in de kist.

Op papier is het veel makkelijker om één consistente set commando's te leren die allemaal dezelfde interface volgen dan een hoop commando's die allemaal hun eigen userinterface hebben.
In praktijk zijn veel van die unix-commando's zo'n goede match voor het probleem dat ze oplossen dat het ook makkelijk en logisch is om een paar eenvoudige opties te leren die binnen de context van die tool goed te begrijpen zijn, zoals 'grep -c' en 'count -c'. 'sort -c' en 'ls -c' heb ik moeten opzoeken, ook al ben ik een professional met 25 jaar ervaring met de unix-commandline.

[DJ Henk]

Het punt dat ik probeer te maken is dat veel van die tools hun eigen pad hebben gevolgd zonder rekening te houden met wat andere tools doen (of vooral, hoe de interface werkt).

Als je het hebt over de interface, dan geef ik je helemaal gelijk. Ik interpreteerde 'samenwerken' en 'design' in puur technische zin, dat is inderdaad wat anders.

[coady]

Het is de laatste jaren wel erg verbeterd, vind ik. Met auto aanvullen van commands en arguments middels tab-knop. Ook de toevoeging van man (manual) per commando is fijn.
Wel is de terminologie binnen verschillende commando's soms erg onduidelijk. Ik gebruik het veel voor Exchange Server en kom dan vaak tegen dat er overlap is tussen termen als name, alias, user etc. Dan is niet helemaal duidelijk welk van de gegevens het commando wilt hebben.

[Vogel666]

De ls in powershell is bij mij even lang als de ls in Debian.
Wellicht moet je Powershell wat meer gebruiken, dan leer je het beter kennen.

Maar het grote punt waarop je waarschijnlijk doelt: Powershell is ontworpen als scripting taal.
Je hebt de overhead van je Windows omgeving toch geinstalleerd staan, dus je hebt geen enkele reden om niet de klik-geit uit te hangen....tenzij je het klikken beu bent en een scheduled task wil maken die de taak voor je uitvoert.

[aikebah]

"ls" is dan ook geen PowerShell commando, maar een compatibility alias voor het PowerShell commando dat er achter ligt: Get-ChildItem

[renecl]

Is dat dan niet veel onveiliger?

[watercoolertje]

Op linux moet je dan een wachtwoord (vingerafdruk/usbkey/oid) invoeren om te bewijzen dat je die gebruiker bent die zich als een andere (super)user voor mag doen.

[biteMark]

Da's mooi.

Op Windows kan het Administrator-account beveiligd zijn met een wachtwoord o.i.d., waarbij je dus alleen gebruikers die je de mogelijkheid wil geven het admin-wachtwoord verstrekt. Voor bedrijfsnetwerken is Windows LAPS een mooie optie, daarmee krijgt het local admin account een tijdelijk wachtwoord dat alleen door bevoegde gebruikers is op te vragen. Wie bevoegd is kan per host worden ingesteld.

[latka]

Sudo kent ook de mogelijkheid dat gebruiker Piet sudo kan runnen als gebruiker Jan en alleen commando xyz kan starten. Heel fijnmazig dus.

[Palm_freemium]

Denk erom, je kunt gebruikers rechten geven om specifieke commando's uit te voeren als een andere gebruiker/administrator maar het is wel "dom".

Als je iemand sudo rechten geeft om iets op te ruimen op /data volume;

sudo rm -rf /data/voorbeeld

Dan werkt dit ook;

sudo rm -rf /data/../home

Sudo is misschien wel fijnmazig, maar niet perse een goede tool om permissies mee te regelen.

Een mooi voorbeeld was bij een klant van ons, die mocht files editen met root, die klant had dus gewoon root access via de vi editor

[latka]

lol. Ja het sudo is wel een fraai voorbeeld van een footgun. Beter om dat soort zaken te regelen via een script waar je dan sudo rechten op geeft (wel opletten: geen tmp files maken en variabelen zijn uit den boze).

[delphium]

Ik ben het met je eens. Sudo wordt vaak gepresenteerd als veilig mechanisme om systeem taken uit te voeren. Mijn ervaring is echter dat mensen al snel niet meer nadenken voor ze sudo ergens voor typen. Zeker als ze ook nog eens de history gebruiken, om snel even iets te doen (rm -rf ./*.jpg, in de verkeerde map).

Zelf log ik altijd, heel bewust in met su -, gevolgd door het rootwachtwoord. De prompt wordt dan rood en zo weet ik zeker dat ik uiterst voorzichtig ben, met alles wat ik invoer.

Sudo is volgens mij ook vooral bedoeld voor multiuser systemen, waarbij die users niet het rootwachtwoord mogen weten. Daar zie ik ook wel degelijk het nut. Op een single user systeem is het vooral een tool om even snel, heel veel schade aan te kunnen richten.

[batjes]

De su - methode gebruik ik zelf ook. Veelal gewenning en meer bewustwording dat je als root bezig bent. Op meerdere distro's autocomplete sudo niet in mappen waar je als die user niet bij mag, maar via sudo wel.

Sudo is naar mijn idee in te veel gevallen: Krijg toegang tot user account en je kan ineens een heel stuk meer. Vaker wel dan niet, zijn het user en sudo wachtwoord van een gebruiker gelijk.

Daarnaast is keer op keer gebleken dat sudo toch best behoorlijke security issues met zich meebrengt.

Su - wil je inderdaad niet in multi-user omgevingen, dus zit je al snel vast aan sudo of doas. UAC van Windows i.c.m. (Azure) Active Directory is beduidend krachtiger en fijnmaziger. Blijf het jammer vinden dat de FOSS wereld nog steeds niet met een betere oplossing is gekomen.

[ninjazx9r98]

Of je een wachtwoord oid moet gebruiken ligt aan de configuratie en is geen kwestie van moeten, het kan ook zonder wachtwoord.
watercoolertje ALL=(ALL) NOPASSWD: ALL

[MrFax]

Bij Windows 11 werkt het via een UAC venster: https://devblogs.microsof...oducing-sudo-for-windows/

[Reactie gewijzigd door MrFax op 22 juli 2024 15:04]

[Croga]

Of je nou sudo typt of rechtsklik "run as administrator" maakt, que veiligheid niet echt uit.

sudo zorgt er voor dat je niet meer "run as administrator" nodig hebt en gewoon voor 1 commando als admin kunt draaien.

Dus nee, het is niet echt onveiliger, soms zelfs gewoon veiliger.

[Remzi1993]

Je kan ook een optie aanvinken dat als je de command prompt of terminal opent dat ie standaard met admin wordt geopend. Elke keer als je CMD opent komt er een Admin popup. En dat is echt handig.

[Wolfos]

Ten eerste een stukje consistentie met andere besturingssystemen, wat altijd mooi is. Ten tweede scheelt het handmatig een nieuwe shell openen wat altijd een beetje een ongemakkelijke handeling is.

Qua functionaliteit voegt het niks nieuws toe. Gewoon een kleine handigheid.

[Reactie gewijzigd door Wolfos op 22 juli 2024 15:04]

[beerse]

Voor de persoonlijke gebruiker/eigenaar van een msWindows gebaseerde desktop/laptop zal het niet veel uit maken.

Voor de beheerders van grotere, genetwerkte omgevingen is het een opening naar meer gedelegeerd beheer en het niet meer hoeven doorgeven van beheer wachtwoorden.

Naar keuze kan sudo zonder wachtwoord werken of vragen om het wachtwoord van de gebruiker die is ingelogd. Dan hoeft het wachtwoord van het account met de rechten (local administrator) niet te worden rondgedeeld. Dat je dan dus 'start-process <cmd> -Verb runAs' gebruikt en niet het wachtwoord van de 'runAs' gebruiker nodig hebt maar je eigen wachtwoord intikt of helemaal geen wachtwoord nodig hebt.

Daarbij kan worden geconfigureerd wat de aanvragende gebruiker wel of niet mag. Tot op welk niveau zal blijken.

Ondertussen vraag ik mij af of en hoe dit van invloed kan zijn op de uac-prompt. Misschien wordt dat ook wel configurabel.

[Reactie gewijzigd door beerse op 22 juli 2024 15:04]

[Vogel666]

Hoppen met credentials kan ook met sudo nog altijd niet...by design...
Dus remote beheer vanaf client A naar server B gaat prima, maar je kunt dan nooit data schrijven naar of ophalen van server C.

[beerse]

Zoals onder unix zijn de linux tools zoals sudo en su gemaakt voor 1 doel: wisselen van account, niet wisselen van machine. Om van machine te wisselen zijn er andere tools zoals rsh (antiek, niet veilig, niet gebruiken) en ssh. Met ssh kan je vanaf 1 machine naar een andere machine om daar taken uit te voeren.

Onder unix en linux is het gebruikelijk dat service accounts en dergelijke niet gebruikt kunnen worden om mee in te loggen, dus ook niet via ssh of zo. Dat is ook niet nodig. Je logt in met je eigen account. De taken die met het service account moeten worden uit gevoerd doe je dan met su of sudo.

En het komt ook vaak voor dat je op de console alleen met root kan en mag inloggen. En dat het account root alleen op de console kan en mag inloggen. Dit om te forceren dat het alleen lokaal gebruikt wordt. Dat je de console vaak weer remote kan benaderen is op dat vlak weer voorzien van de juiste toegangs-eisen.

En terug over ssh: msWindows heeft sinds een paar jaar daar OpenSSH opgepakt en geïmplementeerd, zowel de server als ook de client kant. Als professional werkt in ieder geval de client voor mij goed genoeg. De commandline vanaf de powershell prompt werkt net zo praktisch en met de zelfde configuratie files als onder linux.

[Reactie gewijzigd door beerse op 22 juli 2024 15:04]

[Vogel666]

De kans is groot dat Windows servers in een Windows eco-systeem staan.

HET sellingpoint van Windows omgevingen is de single sign on.
Je maakt 's ochtends 1x een Kerberos TGT aan en hebt de hele dag toegang tot de OS-laag, de applicatielaag en de datalaag van alle resources in je eco-systeem. Het opslaan van credentials in allerlei conf en ini files is daardoor in Windows ook voor services en scheduled tasks nooit nodig.
Het risico zit daar natuurlijk dan ook gelijk in. Om te voorkomen dat men met 1 gehackte TGT door alle security lagen heen kan prikken heeft MS beperkingen opgelegd.

SSH heeft voor een Windows beheerder weinig relevantie, tot hij ook Linux machines gaat beheren.

[beerse]

Misschien heb je binnen het msWindows platform wel gelijk. Misschien mis je een paar handige zaken van ssh:
Om te beginnen biedt ssh private/public key toegang: Helemaal niet meer inloggen maar expliciet van account@machine naar account@machine. 1 keer ingesteld, altijd toegang. Al zal dat waarschijnlijk met passkeys worden ingevuld. Onder water is het praktisch het zelfde.
Daarnaast de inclusieve tunnel die ssh biedt: Al het verkeer tussen de remote en de lokale machine kan via de zelfde ssh-verbinding lopen. Dat is dan meteen op de zelfde beveiliging/versleuteling als de werk-verbinding die al open staat.
En daar bij de bestands-overdracht die met ssh mee komt. Dat wordt meestal als scp aangegeven zoals dat met bijvoorbeeld winscp wordt ingevuld.

Dus ja, ssh wordt ook al tijden bij msWindows gebruikt, al wordt dat niet altijd zo gezien.

[Henk Poley]

Het nadeel is dat zolang als het gestarte proces draait, er ook nog een 'elevated' sudo proces draait met een wagenwijd open ALPC poort waar ieder proces op je computer aanvragen naar toe kan sturen om nog meer programma's met Administrator rechten te starten. https://twitter.com/tiraniddo/status/1755886475563151463

[Cergorach]

@Fermion Sudo bestond al 10 jaar of langer voordat Linux überhaupt werd 'geboren'. Linux heeft het ook ergens vandaan gejat, MacOS gebruikt het, dus waarom zou Windows dat niet mogen?

[Reactie gewijzigd door Cergorach op 22 juli 2024 15:04]

[RitBit]

sudo is veel en veel ouder...
Komt uit de oude Unices in de jaren 80 en 90...

zie: https://en.wikipedia.org/wiki/Sudo

[Gubbel]

Oftewel zoals @Cergorach zegt, zo'n 10 jaar ouder dan Linux..

[Blokker_1999]

Als je Unix en oud in een zin zet verwacht ik daarachter niet de cijfers 80 en 90 te zien maar denk ik aan de jaren 70

[Rembert]

sudo komt uit 1980. Uit begin jaren 70 komt su.
Unix + oud is voor mij voor 1985, het jaar dat ik mijn eerste unix omgeving hackte

[_JGC_]

runas.exe doet hetzelfde lijkt me?

[HooksForFeet]

Runas kan niet elevaten naar admin-rechten als UAC aan staat. Je kan het wel als een admingebruiker runnen, maar je hebt dan nog geen adminrechten. (Net als je geen adminrechten hebt als je gewoon inlogt met een admin-account.)

Het werkt alleen als je het terminalvenster al gestart hebt met adminrechten.

[Reactie gewijzigd door HooksForFeet op 22 juli 2024 15:04]

[WhiteDog]

runas /noprofile /user:<user met admin> "powershell start cmd -v runas"

[Dyon_R]

Zowel de GitHub als de aankondigingspagina werken voor mij, zonder foutmelding of 404.

https://devblogs.microsof...oducing-sudo-for-windows/

https://github.com/microsoft/sudo

[Reactie gewijzigd door Dyon_R op 22 juli 2024 15:04]

[TheVivaldi]

Voor mij ook. cc @arnoudwokke

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 15:04]

[Erendiz]

Als er een nieuwe venster geopend wordt, is dat niks anders dan een alias voor:

Start-Process -Verb RunAs wt

[satya]

Bij Linux worden commando's in principe ook in een subshell uitgevoerd, alleen heb je dat niet door, dat principe zit niet bij Windows ingebakken.

[Fermion]

Interessant, want stiekem onderwater toch linux?

[Vinnie2k]

Als k me niet vergis is het commando 'substitute user, Do!' dus in essentie is dat niet exclusief een handeling die alleen op Linux voorkomt.

Ik zou het fijn vinden om geen elevated venster open te hoeven zetten voor die paar admin commands. En niet in admin modus normale commandos te hoeven draaien.

[Reactie gewijzigd door Vinnie2k op 22 juli 2024 15:04]

[vickypollard]

Het is toch "super user do"?

[RitBit]

nee want je kan ook ander userid's opgeven met de '-u' flag...

Overings stamt het sudo commando uit vroege jaren 80 waar het werdt gebruikt in de verschillende Unices toen en sterk verbeterd de vroege jaren 90.

bron: https://en.wikipedia.org/wiki/Sudo


edit: typo

[Reactie gewijzigd door RitBit op 22 juli 2024 15:04]

[vickypollard]

Nou ja, diezelfde Wiki zegt "It originally stood for "superuser do." Dus ik ben gewoon niet helemaal bij

[Vinnie2k]

Dat is wel de meest gehoorde en de reden dat ik het me herinner. Omdat het dus niet dat is.

Ik geloof dat je met het commando iets met 'root' rechten draait en zonder dat je daadwerkelijk als root inlogd. Ook kan je de machtigingen nog instellen per user, wat die mag met het sudo commando.

Wel is het dus de eenmalige login als "Superuser" oftewel als administrator. Dus ik snap dat dat makkelijker uitleggen is.

[sfranken]

switch user, do

[Lothlórien]

Ik denk inderdaad ook altijd dat het 'superuser do'' maar dat is niet logisch omdat je het super user (root) wachtwoord niet hoeft in te voeren.

sterker nog: met "sudo su", of "sudo su root" kun je nog weleens root worden zonder het root wachtwoord te kennen.

[moredruid]

sudo su (-) of sudo su root kun je ook vervangen door sudo -i. De - achter su zorgt er - net als de -i - voor dat je root profile en .basrc volledig wordt geladen.

[springtouwtje]

interessant weetje, bedankt!

[stimpyMGS]

Nee.

[Ordon]

Wat is het verschil tussen 'runas' en deze 'sudo' in een windows omgeving?

[CH4OS]

Runas elevate naar admin rechten voordat je bijvoorbeeld powershell start. Je hebt dan dus altijd admin rechten. Met sudo kun je tijdens het draaien van scripts of typen van losse commandos, switchen naar een andere user (zoals administrator), maar dat niet per se administrator hoeft te zijn. Je kunt dan dus een kopie actie doen als de user die de rechten heeft, bijvoorbeeld.

[Reactie gewijzigd door CH4OS op 22 juli 2024 15:04]

[mjtdevries]

runas hoeft ook niet perse naar admin rechten.
Ik heb het regelmatig gebruikt om als een andere user in iets te starten. Een andere user die geen admin rechten had.

[CH4OS]

Ah, thanks. Dit wist ik niet. Maar feit blijft wel, dat je de applicatie start als die user, waar je met sudo een enkel (CLI) commando kan laten uitvoeren als een user. Wil je bij de applicatie (met runas) switchen van user, zal je de applicatie moeten herstarten met runas.

[manuarmata]

Ik vraag me af of windows ooit onder de kap een echte unix-achtige bestandsstructuur gaat krijgen en men daarom langzaam maar zeker de commandline omvormt van een DOS commandoset naar een Unix commandoset. de schijf-geörienteerde benadering van een bestandssysteem is inmiddels niet meer van deze tijd.

[nullbyte]

de schijf-geörienteerde benadering van een bestandssysteem is inmiddels niet meer van deze tijd.

Da's een mening, het concept zelf is logisch, tijdloos en evenmin "niet meer van deze tijd" als de file system hierarchy en mount points dat zijn in Linux.

Het is overigens sinds Windows 7 mogelijk om een schijf in een lege NTFS map te mounten zonder drive letter.

[MSalters]

Windows heeft onder de kap een Windows-NT gebaseerde structuur. Die is significant moderner dan de Linux structuur. Maar het feit dat je "de" commandoset benoemt geeft wel aan hoe je idee vertekend is. Ten eerste is het geen DOS commandoset (maar CMD.EXE), en ten tweede is dat maar één commandoset, en nog de beperkte ook. PowerShell is de andere, en die is significant moderner dan alle alternatieven. Zo zijn de commandonamen consistent, is het ding typesafe, unicode-safe zonder hacks, whitespace-sane (geen IFS hacks).

En waar Torvalds maar net afscheid aan het nemen is van de inode-aanname, heeft Windows nooit de beperking gehad dat files een per-filesysteem-uniek nummer moeten hebben.

[biteMark]

Ingetrokken?
https://devblogs.microsof...oducing-sudo-for-windows/
https://github.com/microsoft/sudo