I know I need admin rights to install Docker Desktop; but do I have to be an admin to run it? The documentation doesn't say that I do, and Googling doesn't suggest that either; but if I try to run it as a non-privileged user, the process is killed instantly and I get an event-log entry saying "Process requires elevated rights to run."
I'm running Windows 10 Enterprise in a corporate environment and we have non-privileged accounts. Is Docker Desktop not available in this situation or have I just installed it incorrectly somehow?
As of Docker Desktop 2.4 (possibly earlier, I haven't tested) this is supported. From the Windows installation instructions:
If your admin account is different to your user account, you must add the user to the docker-users group. Run Computer Management as an administrator and navigate to Local Users and Groups > Groups > docker-users. Right-click to add the user to the group. Log out and log back in for the changes to take effect.
I have not tested it, but this article seems to indicate that you can.
TLDR;
Problem
The reason for requiring an admin session is that the Docker client in the default configuration uses a named pipe to connect to the Docker engine and that named pipe can only be accessed by administrators
Solution
To avoid this, you can simple allow your user FullControl access to that named pipe
Original author also provides a powershell tool with sources to help perform this admin task.
The answer appears to be "no". I couldn't understand how everyone else at work had avoided this problem; but then learnt that they had asked for admin rights over their local machines and been granted them! I've only been here for two and a half years ... :|
Latest version of Docker desktop allows this, but the user should be in docker-users group.
If you are using Windows 10 Home edition, then adding multiple groups to a normal users will be a pain, even you use 'netplwiz'.
To add a new group to user you can use the below command in Powershell.
Run the powershell as admin, then execute
net localgroup "docker-users" "<user_name>" /add
I am able to run Docker Desktop from a non-administrator account on my Windows 10 machine. I can also issue docker commands from a non-elevated command prompt or PowerShell prompt. Note that my non-administrator account is a member of the local group docker-users.
Initially, I installed it from my administrator account, and things worked as expected, but only if I stayed logged in as administrator. If I wasn't logged in as administrator, I would get the named pipe error that aboellinger described in his answer.
Simply launching C:\Program Files\Docker\Docker\Docker Desktop.exe from my non-administrator account fixed the issue (after waiting a few seconds for the process to start). It didn't even ask to elevate permissions.
The addition of my user account to group docker-users solved my problem. However, since I'm not running Win10 Pro, the GUI access to account control is not available. Instead I ran PowerShell as admin and added my user account to group docker-users there.
Docker is insecure by design, if a user can run docker command without admin rights (.i.e. belongs to docker group) this basically means that this user can escape the container and become admin on the host. No idea how exactly it can be done on Windows but it "just works" on Linux.
What is the Docker security risk of /var/run/docker.sock?
Related
I am trying to install Docker Desktop to my Windows 10 Professional Build 19042 and receive an installation error even when trying to install as 'Administrator'.
Error: Component CommunityInstaller.ServiceAction failed: Failed to start service: Access is denied ...it is not clear to me what specifically Docker cannot access.
Curious to see if anyone has a solution to this issue.
You may need to add your account to the "docker-users" group. See
https://github.com/docker/for-win/issues/785, especially nfunky response on Aug 10, 2020. I used the following command and it resolved that problem for me where "username" is your Windows username:
net localgroup "docker-users" "username" /add
According to the documentation, first you should control the requirements based on your operating system. Next, uninstall the older versions. For example if you are using windows OS, look at this picture
and make sure these items are active in advance.
plus, make sure Hyper-V is installed and working (check the link above).
Finally, if you have this error message while opening the docker desktop:
You are not allowed to use Docker. You must be in the “docker-users” group
you should add your user to docker-users named group created under Computer Management/user and groups/groups. look at this link
I have installed a drupal 8.8 site using Composer on a Windows 10 pro system and docker and ddev as the development environment.
The drupal site seems to be functioning normally: I see no errors in the drupal log nor when I run ddev describe.
The only exception: Drupal gives me a warning that sites/default/settings.php needs to be write protected. In the past I have done this on a live site using Filezilla, but this is a development only site and it seems Filezilla does not apply permissions on local files--at least, when I right-click the file locally, I do not find a command for changing permissions.
I tried changing the write permissions with Windows 10 itself, but that did not seem to have any effect--I suspect for windows those are different kinds of permissions.
I poked around online and saw something that made me think I could use phpmyadmin to change permissions. Got caught up in that and struggled with it, until getting some help here (How to access phpmyadmin on DDEV Windows 10 pro localhost with SSL record too long error) but it turns out you can't change file permissions with phpmyadmin, apparently.
I tried to use the address that connected me to phpmyadmin in my browser to connect with Putty, but Putty tells me the host does not exist.
So the help I am looking for: how can I change file permissions for sites/default/settings.php in Windows 10 pro localhost running docker/ddev development environment for my drupal site?
Thank you!
I assume you're talking about this warning?
First, you can ignore this warning completely. You're on a local development environment, and so you shouldn't have any concerns about the permissions of settings.php.
Unfortunately, in a Windows environment, you can't make simple permissions changes as Drupal 8 is suggesting that you do.
Note that settings.ddev.php explicitly provides the skip_permissions_hardening option, $settings['skip_permissions_hardening'] = TRUE; to tell Drupal 8 not to try to change permissions on sites/default and sites/default/settings.php because it's just a dev environment and because when Drupal does these things it just makes things harder.
However, to make most things easier on Windows (doesn't solve that problem)...
Use nfs_mount_enabled
I see there are loads of problems with the new "official" Drupal 8.8.0 composer build on Windows. Most of them are due to the composer build making some assumptions about the ability to set time and ownership, but the docker mount used by default (CIFS) has everything owned by root, so the container can't change permissions (even thought they're wide open).
I found that I could get by all of these things by using NFS to mount into the container, and you'll also find it improves performance quite a lot. Set up for NFS by following the instructions at https://ddev.readthedocs.io/en/stable/users/performance/#windows-nfs-setup
Status quo:
We are developing a project at the client side. There's an existing Teradata appliance on the DEV side and one on the production side.
On the DEV side there is more than one supplier and every supplier has its own sub-database. The DBAs are not granted with direct permissions but call macros to create users and databases, grant rights etc. But no SYSDBA permissions on Teradata.
On the PRD side these macros don't exist. Every statement has to be run as is and has to be run automatically (packaged via RPM).
Therefore it is currently impossible to do a complete packaging and integration testing.
We have a Jenkins running which is doing several other tasks. The system is virtual, we're root and we already have an established packaging process.
What we need/ideas: an image of a plain Teradata database we can connect to (remote is ok) and run our DDL scripts.
The idea is to start some kind of image (Docker, VMWare, VirtualBox) which provides a small Teradata installation, we run our DDLs and throw the result away at the end.
Best case would be Docker in this case, but I'm open for ideas. Is there some kind of trial Teradata (v15) which can be used in this case?
I have looked into this (as I need to do the same) and here is what I have found:
You can actually run the VMWare image in Virtualbox (which is what I will be doing).
Once I have the image running I tarred and dumped out the file system at root (/) and I was able to startup docker.
However Teradata Express has also got a RAID1 setup (I think) which are the two vmdks PDISK0 and PDISK1 (SCSI sdb and sbc). I couldn't find a way to replicate this in docker (without spending more time and my time is up on this) so for now I think running in docker is not an option but if someone more familar with docker could find a way to virtualize the RAID1 I am happy to be corrected.
I would like to silently install chocolatey on a series of test agents, and I'm trying to use a TFS build to do so. I have a build step that uses the "Run Powershell on Remote Machines" task. This in turn invokes the ps1 to install chocolatey, from https://chocolatey.org/install.ps1, and I supply the powershell switches as documented on the chocolatey website:
-NoProfile -InputFormat None -ExecutionPolicy Bypass
When I run the build, I receive this error:
System.Management.Automation.RuntimeException: A command that prompts the user failed because the host program or the command type does not support user interaction. Try a host program that supports user interaction, such as the Windows PowerShell Console or Windows PowerShell ISE, and remove prompt-related commands from command types that do not support user interaction, such as Windows PowerShell workflows. ---> System.Management.Automation.RuntimeException: A command that prompts the user failed because the host program or the command type does not support user interaction. Try a host program that supports user interaction, such as the Windows PowerShell Console or Windows PowerShell ISE, and remove prompt-related commands from command types that do not support user interaction, such as Windows PowerShell workflows.
What am I doing wrong? Seems odd that the chocolatey installer required user interaction, I think the whole point of chocolately was silent installs?
It seems you have wrong settings in task "PowerShell on Target Machines". Follow the steps below:
Create a .ps1 file on the target machine and specify the text below:
Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object
System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
In "PowerShell on Target Machines" task, specify the location of the .ps1 file just created.
Queue the build.
Check the screenshot below:
What am I doing wrong? Seems odd that the chocolatey installer
required user interaction, I think the whole point of chocolately was
silent installs?
Typically it goes fully silent, unless there is something (like a proxy) that requires input. It would be best to determine what might be causing the issue by running the install directly on the machine and seeing what happens.
Details
The install.ps1 passes over to chocolateyInstall.ps1, which calls chocolateySetup.psm1.
As you look over that script, you may notice that the install.ps1 uses Write-Output, but that psm1 uses Write-Host in some places. This may or may not cause issues, but it's unlikely given that the script works fine with PowerShell DSC.
So it could be a few things:
Make sure whatever runs that script has Administrator privileges, otherwise you will get an access denied error (unless you specify a different Chocolatey installation location).
Make sure you are not getting hit by needing to put in proxy credentials (which is fixed by the Offline Recommendation below).
Make sure you are not getting hit with not being able to access internet resources (which is also fixed by using offline resources).
It could be something else causing a popup, like needing to install .NET 4.x. Recommend you have the latest .NET Framework in the 4.x series installed prior to installing Chocolatey.
Offline Recommendation
The best recommendation we can give - don't use the internet for any part of this script. If you want reliability, you should have everything internal. That includes the install.ps1 script you are going to use for Chocolatey and the chocolatey.nupkg itself.
Take a read over at https://chocolatey.org/install#completely-offline-install to understand our recommendations.
I'm currently running Vista and I would like to manually complete the same operations as my Windows Service. Since the Windows Service is running under the Local System Account, I would like to emulate this same behavior. Basically, I would like to run CMD.EXE under the Local System Account.
I found information online which suggests lauching the CMD.exe using the DOS Task Scheduler AT command, but I received a Vista warning that "due to security enhancements, this task will run at the time excepted but not interactively." Here's a sample command:
AT 12:00 /interactive cmd.exe
Another solution suggested creating a secondary Windows Service via the Service Control (sc.exe) which merely launches CMD.exe.
C:\sc create RunCMDAsLSA binpath= "cmd" type=own type=interact
C:\sc start RunCMDAsLSA
In this case the service fails to start and results it the following error message:
FAILED 1053: The service did not respond to the start or control request in a timely fashion.
The third suggestion was to launch CMD.exe via a Scheduled Task. Though you may run scheduled tasks under various accounts, I don't believe the Local System Account is one of them.
I've tried using the Runas as well, but think I'm running into the same restriction as found when running a scheduled task.
Thus far, each of my attempts have ended in failure. Any suggestions?
Though I haven't personally tested, I have good reason to believe that the above stated AT COMMAND solution will work for XP, 2000 and Server 2003. Per my and Bryant's testing, we've identified that the same approach does not work with Vista or Windows Server 2008 -- most probably due to added security and the /interactive switch being deprecated.
However, I came across this article which demonstrates the use of PSTools from SysInternals (which was acquired by Microsoft in July, 2006.) I launched the command line via the following and suddenly I was running under the Local Admin Account like magic:
psexec -i -s cmd.exe
PSTools works well. It's a lightweight, well-documented set of tools which provides an appropriate solution to my problem.
Many thanks to those who offered help.
Download psexec.exe from Sysinternals.
Place it in your C:\ drive.
Logon as a standard or admin user and use the following command: cd \. This places you in the root directory of your drive, where psexec is located.
Use the following command: psexec -i -s cmd.exe where -i is for interactive and -s is for system account.
When the command completes, a cmd shell will be launched. Type whoami; it will say 'system"
Open taskmanager. Kill explorer.exe.
From an elevated command shell type start explorer.exe.
When explorer is launched notice the name "system" in start menu bar. Now you can delete some files in system32 directory which as admin you can't delete or as admin you would have to try hard to change permissions to delete those files.
Users who try to rename or deleate System files in any protected directory of windows should know that all windows files are protected by DACLS while renaming a file you have to change the owner and replace TrustedInstaller which owns the file and make any user like a user who belongs to administrator group as owner of file then try to rename it after changing the permission, it will work and while you are running windows explorer with kernel privilages you are somewhat limited in terms of Network access for security reasons and it is still a research topic for me to get access back
Found an answer here which seems to solve the problem by adding /k start to the binPath parameter. So that would give you:
sc create testsvc binpath= "cmd /K start" type= own type= interact
However, Ben said that didn't work for him and when I tried it on Windows Server 2008 it did create the cmd.exe process under local system, but it wasn't interactive (I couldn't see the window).
I don't think there is an easy way to do what you ask, but I'm wondering why you're doing it at all? Are you just trying to see what is happening when you run your service? Seems like you could just use logging to determine what is happening instead of having to run the exe as local system...
Using Secure Desktop to run cmd.exe as system
We can get kernel access through CMD in Windows XP/Vista/7/8.1 easily by attaching a debugger:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\osk.exe" /v Debugger /t REG_SZ /d "C:\windows\system32\cmd.exe"
Run CMD as Administrator
Then use this command in Elevated:
CMD REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\osk.exe" /v Debugger /t REG_SZ /d "C:\windows\system32\cmd.exe"
Then run osk (onscreenkeyboard). It still does not run with system Integrity level if you check through process explorer, but if you can use OSK in service session, it will run as NT Authority\SYSTEM
so I had the idea you have to run it on Secure Desktop.
Start any file as Administrator. When UAC prompts appear, just press Win+U and start OSK and it will start CMD instead. Then in the elevated prompt, type whoami and you will get NT Authority\System. After that, you can start Explorer from the system command shell and use the System profile, but you are somewhat limited what you can do on the network through SYSTEM privileges for security reasons. I will add more explanation later as I discovered it a year ago.
A Brief Explanation of how this happens
Running Cmd.exe Under Local System Account Without Using PsExec. This method runs Debugger Trap technique that was discovered earlier, well this technique has its own benefits it can be used to trap some crafty/malicious worm or malware in the debugger and run some other exe instead to stop the spread or damage temporary. here this registry key traps onscreen keyboard in windows native debugger and runs cmd.exe instead but cmd will still run with Logged on users privileges, however if we run cmd in session0 we can get system shell. so we add here another idea we span the cmd on secure desktop remember secure desktop runs in session 0 under system account and we get system shell. So whenever you run anything as elevated, you have to answer the UAC prompt and UAC prompts on dark, non interactive desktop and once you see it you have to press Win+U and then select OSK you will get CMD.exe running under Local system privileges. There are even more ways to get local system access with CMD
an alternative to this is Process hacker if you go into run as... (Interactive doesnt work for people with the security enhancments but that wont matter) and when box opens put Service into
the box type and put SYSTEM into user box and put C:\Users\Windows\system32\cmd.exe leave the rest click ok and boch you have got a window with cmd on it and run as system now do the other steps for yourself because im suggesting you know them
There is another way. There is a program called PowerRun which allows for elevated cmd to be run. Even with TrustedInstaller rights. It allows for both console and GUI commands.
(Comment)
I can't comment yet, so posting here... I just tried the above OSK.EXE debug trick but regedit instantly closes when I save the filled "C:\windows\system32\cmd.exe" into the already created Debugger key so Microsoft is actively working to block native ways to do this. It is really weird because other things do not trigger this.
Using task scheduler does create a SYSTEM CMD but it is in the system environment and not displayed within a human user profile so this is also now defunct (though it is logical).
Currently on Microsoft Windows [Version 10.0.20201.1000]
So, at this point it has to be third party software that mediates this and further tricks are being more actively sealed by Microsoft these days.
if you can write a batch file that does not need to be interactive, try running that batch file as a service, to do what needs to be done.
I use the RunAsTi utility to run as TrustedInstaller (high privilege). The utility can be used even in recovery mode of Windows (the mode you enter by doing Shift+Restart), the psexec utility doesn't work there. But you need to add your C:\Windows and C:\Windows\System32 (not X:\Windows and X:\Windows\System32) paths to the PATH environment variable, otherwise RunAsTi won't work in recovery mode, it will just print: AdjustTokenPrivileges for SeImpersonateName: Not all privileges or groups referenced are assigned to the caller.
Using task scheduler, schedule a run of CMDKEY running under SYSTEM with the appropriate arguments of /add: /user: and /pass:
No need to install anything.
i used Paul Harris recommendation and created a batch file .cmd or .bat with what ever command i needed to run under system and used the schedule task run one time.
than trigger it as needed. and updated the batch as needed. so any command i need to run under system i just update the batch.