-
Notifications
You must be signed in to change notification settings - Fork 661
[socketVMNet] Disable symlink detection for the socketVMNet directory #1437
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
Comments
@lima-vm/maintainers Can we just trust the symlink when it is owned by the |
We would also need to check the target where the symlink points to, and all parent directories of the target, to make sure all of them are only writable by admin users. And do this recursively if any of those directories turn out to be symlinks. |
do you think that the |
It has already been relaxed in #1220 to make it easier for Homebrew users. I feel uneasy about that already because it is not different from allowing password-less sudo access for the admin user. Which maybe is acceptable, but it should be something the user explicitly configures, and not a side-effect of the configuration of socket_vmnet. So if anything, I think the verification should be stricter. You should be able to delete the Just paste something like |
as stated in the #2662 (comment) this will work if only my user is a member of the admin group, for example, if my primary group is "staff", it won't work even if my user name is in the sudoers file, due to: Line 103 in 619a4ca
|
I believe loosening the restrictions to allow ownership by There are ways to install/run the daemon securely as an unmanaged launchdaemon. For convenience Lima allows you to create sudoers rules to run just the commands needed to start/stop the daemon as If this is not a concern, then you can enable password-less sudo and Lima will skip all file ownership checks. You don't even need the sudoers file. I've just tested it myself: $ limactl create --tty=false template://vmnet
…
INFO[0000] Run `limactl start vmnet` to start the instance.
$ limactl start vmnet
INFO[0000] Using the existing instance "vmnet"
FATA[0000] can't read "/private/etc/sudoers.d/lima": failed to run [sudo --user root --group wheel --non-interactive true]: exit status 1: (Hint: run `limactl sudoers >etc_sudoers.d_lima && sudo install -o root etc_sudoers.d_lima "/private/etc/sudo
$ yq -i 'del(.paths.sudoers)' ~/.lima/_config/networks.yaml
$ echo "%admin ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/nopasswd >/dev/null
Password:
$ limactl start vmnet
INFO[0000] Using the existing instance "vmnet"
INFO[0000] Starting socket_vmnet daemon for "shared" network
INFO[0000] Starting the instance "vmnet" with VM driver "qemu" |
This is all valid if a user is a member of the admin group ( My user is not a member of the admin group for the sake of said security, however is added in the sudoers list as |
Can you provide the output? Also, what happens when you run |
I just realized that you have a EDIT: Actually, I'm not sure if the user.name itself is an issue; maybe it is creating Anyways, seeing the actual error message might help. |
@jandubois I assume you're referring to a caveat when a sudoers file has a dot somewhere in its file name, in this case my sudoers file name has no dots in it the output of the the
my sudoers config allows me to use password-less sudo:
I'm able to create a new limactl VM:
but I cannot start it:
as you may see, the socket_vmnet directory is owned by the
|
The issue I have had reported before is now fixed 👍 |
Description
Currently, when Lima is installed for the first time on macOS, it will automatically create a
~/.lima/_config/networks.yaml
configuration file, in whichsocketVMNet
is automatically filled with a non-symlink directory.But when we update
socketVMNet
throughbrew
command, the old version directory may be deleted, which will cause Lima to fail to start.If we set the
socketVMNet
directory to/opt/homebrew/opt/socket_vmnet/bin/socket_vmnet
(this directory is a symlink maintained by brew.), it will also cause startup failure due to internal detection mechanism.Can we use some compatible code to allow the
socketVMNet
directory to use symlink?The text was updated successfully, but these errors were encountered: