unexpected permission change of /run/user/$UID #4846

bundi78 · 2020-01-12T19:55:10Z

/kind bug

Description

Running a container with a modified uidmap (eg. --userns=keep-id) leads to an unexpected permission change of /run/user/$UID (from (7)700 to (7)711). Which in turn leads to a malfunction of the KDE plasma desktop i'm using.

Steps to reproduce the issue:

stat -c "%a %n" /run/user/$UID
podman run --rm -it --userns=keep-id docker.io/archlinux/base
stat -c "%a %n" /run/user/$UID

Describe the results you received:

Opening the file dialog of a KDE app like kate leads to an error message: "can not create socket..."

Additional information you deem important (e.g. issue happens only occasionally):

After manually fixing the permission back to 7700, the KDE apps are working.

The permission is also changed when using --uidmap.

Output of podman version:

Version: 1.7.0
RemoteAPI Version: 1
Go Version: go1.13.5
Git Commit: b7ce115-dirty
Built: Sat Jan 11 13:49:39 2020
OS/Arch: linux/amd64

(same before podman update from 1.6.1 to 1.7.0)

Output of podman info --debug:

debug:
compiler: gc
git commit: b7ce115-dirty
go version: go1.13.5
podman version: 1.7.0
host:
BuildahVersion: 1.12.0
CgroupVersion: v1
Conmon:
package: Unknown
path: /usr/bin/conmon
version: 'conmon version 2.0.3, commit: eb5fa88c26fde5ce1e3f8a1d2a8a9498b2d7dbe6'
Distribution:
distribution: arch
version: unknown
IDMappings:
gidmap:

container_id: 0
host_id: 1000
size: 1
container_id: 1
host_id: 1000000
size: 65536
uidmap:
container_id: 0
host_id: 1000
size: 1
container_id: 1
host_id: 1000000
size: 65536
MemFree: 6480297984
MemTotal: 16747290624
OCIRuntime:
name: runc
package: Unknown
path: /usr/bin/runc
version: |-
runc version 1.0.0-rc9
commit: d736ef14f0288d6993a1845745d6756cfc9ddd5a
spec: 1.0.1-dev
SwapFree: 39280701440
SwapTotal: 39280701440
arch: amd64
cpus: 8
eventlogger: file
hostname: dev1
kernel: 5.4.10-1-ck
os: linux
rootless: true
slirp4netns:
Executable: /bin/slirp4netns
Package: Unknown
Version: |-
slirp4netns version 0.4.2
commit: 69153b0d1cb82216d6782179ff7c3c5e91c731a1
uptime: 3h 57m 2.76s (Approximately 0.12 days)
registries:
localhost:
Blocked: false
Insecure: true
Location: localhost
MirrorByDigestOnly: false
Mirrors: []
Prefix: localhost
search:
docker.io
registry.fedoraproject.org
quay.io
registry.access.redhat.com
registry.centos.org
store:
ConfigFile: /home/developer/.config/containers/storage.conf
ContainerStore:
number: 1
GraphDriverName: overlay
GraphOptions:
overlay.mount_program:
Executable: /bin/fuse-overlayfs
Package: Unknown
Version: |-
fusermount3 version: 3.9.0
fuse-overlayfs: version 0.7.2
FUSE library version 3.9.0
using FUSE kernel interface version 7.31
GraphRoot: /home/developer/.local/share/containers/storage
GraphStatus:
Backing Filesystem: btrfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
ImageStore:
number: 1
RunRoot: /run/user/1000/containers
VolumePath: /home/developer/.local/share/containers/storage/volumes

Additional environment details (AWS, VirtualBox, physical, etc.):

I'm using an up-to-date arch linux, last system upgrade today. This is happening on a second machine (also arch linux) too.

I tried a podman system reset but no change.

The text was updated successfully, but these errors were encountered:

mheon · 2020-01-12T20:05:21Z

@giuseppe PTAL.

I want to say this is the userns code adding +x to allow the other users mapped into the user namespace to access container files, but I'm not sure what specifically it would need to access in the container tmpdir.

Can you provide more details on the KDE errors as well? I don't know why adding execute permissions for group+all on that directory would cause KDE to not work.

giuseppe · 2020-01-13T09:10:41Z

I want to say this is the userns code adding +x to allow the other users mapped into the user namespace to access container files, but I'm not sure what specifically it would need to access in the container tmpdir.

yes correct. The userns code changes the directory permissions so that an user != your UID can access the storage and the tmpdir.
When a user namespace is used and root in the namespace != your UID (as it happens with --userns=keep-id), the runtime init process will run as the root in the user namespace and perform operations like setting up the tty as such user. If we weren't tweaking the permission mask, the root in the user namespace would not be able to access these directories/files.

bundi78 · 2020-01-13T16:05:40Z

This is a parts of the syslog:

Jan 10 15:33:15 dev1 kate[21540]: QStandardPaths: wrong permissions on runtime directory /run/user/1000, 7711 instead of 7700
Jan 10 15:33:15 dev1 kate[21540]: kf5.kio.core: KIO Connection server not listening, could not connect
Jan 10 15:33:15 dev1 kate[21540]: kf5.kio.core: couldn't create slave: "Can not create socket for launching io-slave for protocol 'file'."

This is all I could find to narrow the problem, sorry.

mheon · 2020-01-13T16:11:48Z

So it explicitly required 0700. Interesting.

I don't really know what we can do about this aside from moving our temporary files dir out of /run/user.

rhatdan · 2020-01-13T17:50:46Z

Can we create a subdir containers and put them in the subdir?

mheon · 2020-01-13T18:51:13Z

Without execute on the top-level /run/user/$UID that won't help us - I believe we need execute on every level from root in order to access the directory in question.

rhatdan · 2020-01-13T20:57:41Z

If the container process is walking the path it would but if this is volume mounted into the container then it does not. At least that is what I understand. @giuseppe would know for sure.

giuseppe · 2020-01-14T12:28:59Z

If the container process is walking the path it would but if this is volume mounted into the container then it does not. At least that is what I understand. @giuseppe would know for sure.

it looks like changing the permissions for the rundir and the tmpdir is not needed anymore. I've tested it both with runc and crun.

I've opened a PR here: #4859

do not change the permissions mask for the rundir and the tmpdir when running a container with a user namespace and the current user is mapped inside the user namespace. The change was introduced with 849548f, that dropped the intermediate mount namespace in favor of allowing root into the user namespace to access these directories. Closes: containers#4846 Signed-off-by: Giuseppe Scrivano <[email protected]>

CleanHit · 2020-10-13T11:51:12Z

I'm having the same issue as described above. I ran my podman run command with -u sync so I don't know if that the source of my problem. Before running the run command I have this output:

stat -c "%a %n" /run/user/$UID
700 /run/user/1001

And after the run command it was:

stat -c "%a %n" /run/user/$UID
711 /run/user/1001

After that some of my applications e.g. the Dolphin browser don't work anymore saying wrong permissions on runtime directory /run/user/1001, 7711 instead of 7700.

Output of podman version:

Version:      2.1.1
API Version:  2.0.0
Go Version:   go1.14.9
Built:        Wed Sep 30 21:31:11 2020
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.16.1
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.21-2.fc32.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.21, commit: 81d18b6c3ffc266abdef7ca94c1450e669a6a388'
  cpus: 8
  distribution:
    distribution: fedora
    version: "32"
  eventLogger: journald
  hostname: linux.fritz.box
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
  kernel: 5.8.13-200.fc32.x86_64
  linkmode: dynamic
  memFree: 8060645376
  memTotal: 33517277184
  ociRuntime:
    name: runc
    package: containerd.io-1.2.13-3.2.fc31.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc10
      commit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
      spec: 1.0.1-dev
  os: linux
  remoteSocket:
    path: /run/user/1001/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.4-1.fc32.x86_64
    version: |-
      slirp4netns version 1.1.4
      commit: b66ffa8e262507e37fca689822d23430f3357fe8
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 2
  swapFree: 17184059392
  swapTotal: 17184059392
  uptime: 4h 0m 4.74s (Approximately 0.17 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/<my_user>/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.1.2-1.fc32.x86_64
      Version: |-
        fusermount3 version: 3.9.1
        fuse-overlayfs: version 1.1.0
        FUSE library version 3.9.1
        using FUSE kernel interface version 7.31
  graphRoot: /home/<my_user>/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 0
  runRoot: /run/user/1001/containers
  volumePath: /home/<my_user>/.local/share/containers/storage/volumes
version:
  APIVersion: 2.0.0
  Built: 1601494271
  BuiltTime: Wed Sep 30 21:31:11 2020
  GitCommit: ""
  GoVersion: go1.14.9
  OsArch: linux/amd64
  Version: 2.1.1

I use Fedora 32 and I also tried podman system reset without any success as in the original post.

giuseppe · 2020-10-13T11:58:33Z

podman needs to make the directory accessible otherwise the user in a user namespace cannot access it (--userns=keep-id).

openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Jan 12, 2020

giuseppe mentioned this issue Jan 14, 2020

oci_conmon: not make accessible dirs if not needed #4859

Merged

openshift-merge-robot closed this as completed in #4859 Jan 15, 2020

github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 22, 2023

github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

unexpected permission change of /run/user/$UID #4846

unexpected permission change of /run/user/$UID #4846

bundi78 commented Jan 12, 2020

mheon commented Jan 12, 2020

giuseppe commented Jan 13, 2020

bundi78 commented Jan 13, 2020

mheon commented Jan 13, 2020

rhatdan commented Jan 13, 2020

mheon commented Jan 13, 2020

rhatdan commented Jan 13, 2020

giuseppe commented Jan 14, 2020

CleanHit commented Oct 13, 2020 •

edited

Loading

giuseppe commented Oct 13, 2020

unexpected permission change of /run/user/$UID #4846

unexpected permission change of /run/user/$UID #4846

Comments

bundi78 commented Jan 12, 2020

mheon commented Jan 12, 2020

giuseppe commented Jan 13, 2020

bundi78 commented Jan 13, 2020

mheon commented Jan 13, 2020

rhatdan commented Jan 13, 2020

mheon commented Jan 13, 2020

rhatdan commented Jan 13, 2020

giuseppe commented Jan 14, 2020

CleanHit commented Oct 13, 2020 • edited Loading

giuseppe commented Oct 13, 2020

CleanHit commented Oct 13, 2020 •

edited

Loading