Why symlinks from mounted macos folders are broken?

[ssbarnea]

I configured podman-machine (4.2.1) on macos correctly in order to allow mounting folders from inside user home directory (guide here)

While mounting seems to be working fine, I observed that all symlinked files are reporting broken, even if I only had a relative symlink pointing to the same file.

ssbarnea@macos:
$ ls -la .prettierignore
lrwxr-xr-x  1 ssbarnea  staff  10 Mar  7  2022 .prettierignore -> .gitignore

# inside the container:
[root@89fe2707de2c ansible-lint]# ls -la .prettierignore
ls: cannot read symbolic link '.prettierignore': Too many levels of symbolic links
lrwxr-xr-x. 1 root nobody 10 Mar  7  2022 .prettierignore

Based on the image the error could vary a little bit but the idea is kinda the same:

ls: ./.prettierignore: cannot read link: Symbolic link loop

Apparently there is also another problem, I created file from within the container with touch foo.txt and when I look at the same file from my macos machine, I seen some weird file permissions:

# From macos:
-rw-r--r--      1 ssbarnea  staff    10547 Aug 11 16:45 foo.log
-rw-------@     1 ssbarnea  staff        0 Oct 10 10:03 foo.txt

$ xattr -l foo.txt
user.virtfs.gid: �
user.virtfs.mode: ��
user.virtfs.uid: �

foo.log was created from mac, and has the correct expected permissions, but the one created from inside the container seems to lack group and others read permissions. Also the @ at the end indicates presence of extended file attributes, something bit unexpected.

I do mention that the container was starting using podman run -v $(pwd):$(pwd) -it quay.io/ansible/creator-ee:latest /bin/bash, which is a container that uses root as default user.

I am not sure if that is the source of the problem, but I am looking for a solution where symlinks would work and where newly created files would not have unexpected permissions.

[afbjorklund]

The default security model uses xattr to store the linux file permissions, instead of storing them as a separate file.

https://wiki.qemu.org/Documentation/9psetup

security_model=mapped-xattr|mapped-file|passthrough|none: Specifies the security model to be used for this export path. Security model is mandatory only for "local" fsdriver. Other fsdrivers (like "proxy") don't take security model as a parameter.
Recommended option is "mapped-xattr".
passthrough: Files are stored using the same credentials as they are created on the guest. This requires QEMU to run as root.
mapped: Equivalent to "mapped-xattr".
mapped-xattr: Some of the file attributes like uid, gid, mode bits and link target are stored as file attributes. This is probably the most reliable and secure option.
mapped-file: The attributes are stored in the hidden .virtfs_metadata directory. Directories exported by this security model cannot interact with other unix tools.
none: Same as "passthrough" except the sever won't report failures if it fails to set file attributes like ownership (chown). This makes a passthrough like security model usable for people who run kvm as non root.

Preserving symlinks or ownership from the host, was not in the original implementation (i..e default security_model).

See https://docs.podman.io/en/latest/markdown/podman-machine-init.1.html

[ssbarnea]

@afbjorklund I replaced security_model=none and I can report that symlinks are working correctly and also newly created files have expected permissions. Not sure why default is mapped-xattr because it is very unlikely to be what a macos user (developer) would want.

The most common use on macos, is for a developer to want to mount some code from within his user home and use it inside a container. Maybe a variation to this would be to run it as read-only, but I do not see many other uses.

Basically the list of things that are broken by default, keeps growing. I hope we can slowly sort these so installing a working podman on macos would be only a simple brew install podman, without extra stuff after.

[afbjorklund]

Hard to guess what the user wants, the qemu implementation goes for the safer default option so the podman implementation followed. It also did not expose the users home directory by default, since that is another security issue. So expectations vary, between users.

• Mount $HOME:$HOME by default in podman machine init #13849

It would be possible to change the default invocation in podman, to use the "none" security model by default... But not retroactively.

volumes = [
  "$HOME:$HOME:ro,security_model=none",
]

EDIT: It is actually not in podman, but in containers.conf (i.e. containers-common).

[ssbarnea]

Out of curiosity I tried using init to create a machine that already has the desired security model, with podman machine init --cpus=4 --memory=4096 -v $HOME:$HOME:security_model=none new but apparently it did not put security_model=none inside. I guess that extra arguments do not get translated into the vm config.

[afbjorklund]

It worked OK here, with podman-remote v4.2.1

My -v "$HOME:$HOME:ro,security_model=none" init parameter got successfully translated to -virtfs local,path=/home/anders,mount_tag=vol0,security_model=none,readonly qemu parameter.

Sounds like a bug ? I was using Ubuntu

[rhatdan]

Please open a PR to change the default.
@baude WDYT?

[bugfood]

Please open a PR to change the default. @baude WDYT?

For anybody that relies on the default of mapped-xattr, that would be a breaking change. Not that I'm opposed to it personally...

I would make a PR, but I can't test it--I shipped back the mac laptop I had on loan. It should be easy for anybody to change and test, though. See the original PR for reference:
03ee820

• change mapped-xattr to none in pkg/machine/qemu/machine.go
• update docs/source/markdown/podman-machine-init.1.md accordingly

[ssbarnea]

GHA can be used to test podman on macos on CI.