Podman: rootless `podman run` with :Z results into "relabel failed"

[TomasTomecek]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

I am mounting my cwd into rootless container using :Z and podman errors out with a message:

relabel failed "/home/tt/g/user-cont/packit": operation not permitted

The reason I am opening this issues is that it works fine for my colleague with the exactly same setup. Hence I am confused whether this is actually supposed to work or not. CC @jpopelka

$ ls -Z -d .
system_u:object_r:container_file_t:s0:c240,c746 .

$ podman run --rm -ti -v $PWD:/src:Z fedora:29 bash
relabel failed "/home/tt/g/user-cont/packit": operation not permitted

$ podman run --rm -ti -v $PWD:/src fedora:29 bash
[root@ea90caf155f2 /]# exit

Output of podman version:

Version:       1.0.0
Go Version:    go1.11.4
Git Commit:    "49780a1cf10d572edc4e1ea3b8a8429ce391d47d"
Built:         Mon Jan 14 21:38:17 2019
OS/Arch:       linux/amd64

[mheon]

@rhatdan Do we have permissions to do :z and :Z with rootless?

[giuseppe]

we have no way for setting that xattrs as rootless

[mheon]

Hm. We handle these inside libpod, so we can easily pop up a more helpful error on a relabel being requested.

[rhatdan]

@giuseppe Why not? You should be able to relabel a directory from an SELinux point of view.
Is this caused by fuse-overlay?

[rhatdan]

@TomasTomecek If you try in permissive mode, is it allowed?

[TomasTomecek]

sadly, not:

$ sudo setenforce 0
$ podman run --rm -ti -v $PWD:/src:Z fedora:29 bash
relabel failed "/home/tt/g/user-cont/packit": operation not permitted  

[rhatdan]

Well I would like to know what is blocking it. If I just do a buildah unshare I am allowed to set the label.

[TomasTomecek]

I have no idea either. I was able to do restorecon -FR with my unprivileged user. When running podman with strace, it actually hanged and I didn't get any meaningful output.

[giuseppe]

@giuseppe Why not? You should be able to relabel a directory from an SELinux point of view.
Is this caused by fuse-overlay?

it should not interfere with fuse-overlay as it is bind mounted on top of it.

[rhatdan]

This worked for me

 podman run -ti -v ~/test:/test:Z fedora sh
Trying to pull docker.io/fedora:latest...Getting image source signatures
Skipping blob 2ec1fbfd44b7 (already present): 85.73 MiB / 85.73 MiB [=======] 0s
Copying config d7372e6c93c6: 1.99 KiB / 1.99 KiB [==========================] 0s
Writing manifest to image destination
Storing signatures
sh-4.4# ls -lZ /test 
-rw-rw-r--. 1 root root system_u:object_r:container_file_t:s0:c194,c214 8 May 11  2010 /test
sh-4.4# exit
exit

rpm -q podman
podman-1.0.0-1.git82e8011.fc29.x86_64

[rhatdan]

What file system were you sitting in when you ran?

podman run --rm -ti -v $PWD:/src:Z fedora:29 bash
relabel failed "/home/tt/g/user-cont/packit": operation not permitted

Is this on an nfs share or some file system that does not support labeling?

[TomasTomecek]

It's standard XFS on top of luks filesystem:

$ mount | grep 'on / '
/dev/mapper/luks-460d57c9-ef38-46d4-9bb1-f31b6c0feef5 on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

$ findmnt /
TARGET SOURCE                                                FSTYPE OPTIONS
/      /dev/mapper/luks-460d57c9-ef38-46d4-9bb1-f31b6c0feef5 xfs    rw,relatime,seclabel,attr2,inode64,noquota

I don't even have a separate /home partition.

[rhatdan]

Have you tried different directories? Could you try chcon -t container_file_t -R SOURCE
outside of the container and see if it fails?

[TomasTomecek]

Thanks, Dan! That command finally helped me to resolve it: the problem was that there were files/dirs owned by root down the road which I didn't notice originally, hence the operation denied message.

Sorry for the fuss.

[rhatdan]

Interesting. Files owned outside the user namespace that were not allowed to be relabelled.

[abitrolly]

I've got root owned files in my local dir after I run docker and then tried the same command with podman.

[mheon]

Root owned? That's unusual. We'd expect ownership by a high UID/GID if
you're using rootless.

On Mon, May 6, 2019, 07:20 Anatoli Babenia [e-mail] wrote:

I've got root owned files in my local dir after I run docker and then
tried the same command with podman.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/containers/libpod/issues/2379#issuecomment-489586312,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB3AOCA2IKBDDLQPYM456XLPUAIA7ANCNFSM4GYUT5LQ
.

[abitrolly]

These are created by docker run,

✗ git clone https://github.com/yakshaveinc/linux
✗ cd linux
✗ docker run -v $PWD:/src:Z -w /src yakshaveinc/snapcraft:core18-edge snapcraft
...
✗ find . -group root
./parts
./parts/yakshaveinc
./parts/yakshaveinc/state
./parts/yakshaveinc/state/stage
./parts/yakshaveinc/state/build
./parts/yakshaveinc/state/prime
./parts/yakshaveinc/state/pull
./parts/yakshaveinc/install
./parts/yakshaveinc/src
./parts/yakshaveinc/build
./parts/.snapcraft_global_state
./stage
./prime
./prime/meta
./prime/meta/snap.yaml

[rhatdan]

Podman is running as your user UID, and would not be allowed to change files owned by root. This is expected