Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide an option to allow Orbstack to improve Docker socket compatibility by default without entering password #281

Closed
sp213 opened this issue May 21, 2023 · 10 comments
Labels
f/containers Affects container users t/feature New feature
Milestone

Comments

@sp213
Copy link

sp213 commented May 21, 2023

Is your feature request related to a problem? Please describe.
Given I set OrbStack to start automatically each time I reboot my Mac, there's an annonying pop up showing "OrbStack wants to improve Docker socket compatibility. This is optional. Enter your password to allow this".

Describe the solution you'd like
I don't want this popup, so how can I get rid of this? I think maybe we just need to setup once in OrbStack to allow this then next time I reboot my Mac, this popup will dispear. Thank you.

@sp213 sp213 added the t/feature New feature label May 21, 2023
@halostatue
Copy link

halostatue commented May 21, 2023

I have the same request for the opposite reason: I explicitly do not want to "improve Docker socket compatibility" under any circumstances. This should prompt once (do you want to do X) and if the answer is no, never ask again unless a button is pushed in settings. Only after that prompt should it ask for my password again. Combining authorization (to make the change) and permissions elevation (the effective-sudo to make the socket link) in a single dialog is not great security UX.

@sp213
Copy link
Author

sp213 commented May 22, 2023

Yes, anyway I just don't want Orbstack to prompt everytime I restart my computer.

@kdrag0n
Copy link
Member

kdrag0n commented May 22, 2023

We'll add a privileged helper tool to deal with this.

The other case of permanently declining admin is another issue. I agree that we should handle it better, but good UX will be a little tricky because macOS doesn't allow adding anything to the authorization prompt (so no checkbox). Accidentally dismissing the prompt is likely far more common than intentionally declining it, so we might require several dismissals to make it permanent.

@kdrag0n
Copy link
Member

kdrag0n commented May 22, 2023

Also, it's perfectly fine to decline the Docker socket symlink now, but in the future there will likely be more lost functionality as we add more privilege-dependent features in the future. It'll have to be a general setting for the entire helper tool.

@sp213
Copy link
Author

sp213 commented May 22, 2023

Thank you!

@halostatue
Copy link

Also, it's perfectly fine to decline the Docker socket symlink now, but in the future there will likely be more lost functionality as we add more privilege-dependent features in the future. It'll have to be a general setting for the entire helper tool.

In general, I’m looking at this from the perspective that "good" container software knows about contexts, and as I’m not on Linux and not using Docker Desktop, I don’t want to have the symlink under any circumstances (I will temporarily set DOCKER_HOST if I really need the software). Other privileged permissions…I’d need to see what they are. In general, I’m looking at trying to reduce permissions required (I’ve been looking at podman).

@kdrag0n kdrag0n added the f/containers Affects container users label May 24, 2023
@kdrag0n kdrag0n modified the milestone: v0.11.1 May 24, 2023
@halostatue
Copy link

Also, it's perfectly fine to decline the Docker socket symlink now, but in the future there will likely be more lost functionality as we add more privilege-dependent features in the future. It'll have to be a general setting for the entire helper tool.

I wanted to follow up on the bit about privilege-dependent features specifically. I think that there probably needs to be settings for the helper tool when you get to that. As I said in my previous reply, I will never want the docker sock link, even if I opt into other privilege-dependent features. That’s something that is fundamentally non-negotiable for me, because even for socket-based approaches, modern docker uses contexts and good applications that interact with docker should understand contexts, and setting $DOCKER_HOST is the way to work around those misbehaving applications.

@ooboqoo
Copy link

ooboqoo commented Jun 15, 2023

Quick solution before feature landed: You can utilize a macOS Launch Daemon to automatically establish a symlink from /var/run/docker.sock to /Users/<your_username>/.orbstack/run/docker.sock during system startup.

Add file /Library/LaunchDaemons/com.orbstack.docker.sock.plist (P.S. replace <your_username> with your username here).

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>com.orbstack.docker.sock</string>
    <key>ProgramArguments</key>
    <array>
      <string>ln</string>
      <string>-sf</string>
      <string>/Users/<your_username>/.orbstack/run/docker.sock</string>
      <string>/var/run/docker.sock</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

Then load it sudo launchctl load /Library/LaunchDaemons/com.orbstack.docker.sock.plist

@kdrag0n
Copy link
Member

kdrag0n commented Aug 15, 2023

Changes made for the next version:

  • Setting to disable admin from the CLI or GUI
  • Privileged helper tool, so authorization is only needed once
  • Auto-disabled if prompt is dismissed multiple times

@kdrag0n kdrag0n closed this as completed Aug 15, 2023
@kdrag0n kdrag0n added this to the v0.16.1 milestone Aug 15, 2023
@kdrag0n
Copy link
Member

kdrag0n commented Aug 18, 2023

Released in v0.16.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
f/containers Affects container users t/feature New feature
Projects
None yet
Development

No branches or pull requests

4 participants