What is dangerous about mounting home writeable?

[tmewett]

In the default config, there is:

mounts:
  - location: "~"
    # CAUTION: `writable` SHOULD be false for the home directory.
    # Setting `writable` to true is possible, but untested and dangerous.
    writable: false

I was wondering what kinds of failure modes we should expect from a writeable home, and if any data loss has ever been observed. It would help users evaluate the risks. E.g. am I only worried about individual files being corrupted if errors occur? Or my entire home being deleted by some freak mounting issue? I appreciate this may deliberately err on the side of caution and failures are not well-known, but any info would be great. Thank you :)

[jandubois]

I believe this is just being cautious in general. In a way any software can cause catastrophic data loss.

Just as a point of reference, both Rancher Desktop and Colima (both of which use Lima under the hoods) have switched to mounting the home directory as writable for practical considerations.

@AkihiroSuda Will we ever change the default setting for Lima? If we want to, what would be the condition to enable this? If we say we don't trust sshfs, then we obviously will have to wait until we switch to something else. But otherwise I'm not sure what we would be waiting for.

[AkihiroSuda]

@AkihiroSuda Will we ever change the default setting for Lima? If we want to, what would be the condition to enable this? If we say we don't trust sshfs, then we obviously will have to wait until we switch to something else. But otherwise I'm not sure what we would be waiting for.

We may reconsider the default after we get virtio-9p-pci.

[afbjorklund]

What is the main use case for mounting the home directory ? Is it to access credentials from ~/.docker and ~/.ssh ?
Or is to access the current project files, which are just assumed to be stored somewhere under the home directory ?

Just wondering, seems like most the files that I edit are under /home/anders.linux rather than the remote /home/anders
Even if read-only, there are still the security and performance implications of exporting the home directory from the host.

[afbjorklund]

In a way any software can cause catastrophic data loss.

I think data loss on the virtual machine is to be "expected"...
Not so on the host itself, which could be assumed to be separate.
Think it was even worse before* though, when all users were exported.

* as in Docker Toolbox, which exported /home /Users /C/Users

[msimkunas]

@afbjorklund Sorry for bumping an old thread but I was pondering the question of vm volatility so I thought I would just add my thoughts here.

If you're treating your vm as an intermediary layer that provides you access to containers, this probably means that your vm is ephemeral. In this case, mounting the home dir can be useful if you want to access credentials, such as the ones in .npmrc or .docker/.

If, on the other hand, you're working with a virtual machine mindset like I do, you'll likely treat your vm as a more permanent solution that is not disposable (very much like a typical VM via VMware Fusion, for example – you wouldn't expect your Windows on a VM to just disappear and be easily recreated). In this use case mounting the home dir is less important because you might just end up storing certain files inside the vm, including credentials.

In any case, credentials are revokable and should eventually expire so even if you lose them it's pretty trivial to recreate them.

[afbjorklund]

Typically the registry credentials are stored with the client, and typically only the server is running in the VM. (Docker Machine)

There are exceptions (like k8s), and then the VM usually gets a copy of the credentials (as in a secret / token), if it needs it.

[msimkunas]

That is true for environments that are supposed to be disposable and instantly reproducible. In such scenarios you'll want some sort of a mechanism for sharing secrets.

But it's an unnecessary layer of complexity in systems where the VM is not supposed to be disposable. I've been using a single dev VM for years on my own laptop. I maintain it like I maintain my host OS so in this case I think it makes perfect sense to just keep certain secrets inside the VM (btw, I'm glad Lima has the protect/unprotect commands – this maps perfectly with my use case because I don't want to delete my main dev VM).

[afbjorklund]

Long-lived virtual machines has not been the main goal, and in some cases (like desktops) are better served with other tools. It should be possible to do them with Lima, but the default use case is about the ephemeral. We could do a better job with disks*.

* like backup, or keeping the OS and data disk images separate. Stuff like that. It was easier in "machine" and tinycore (since the OS was read-only, everything that needed to be persistent was on the disk). But better with a new discussion, than this old one.