Unable to access /dev/tty0 in a rootless container #18845

GrabbenD · 2023-06-10T11:55:16Z

Issue Description

I'm attempting to run Sway in rootless container but I'm unable to access /dev/tty0 thus I can't create a graphical session.

Possibly related: #15878

Here's what I've tried:

Passing --device /dev/tty0 without success: ls: cannot access '/dev/tty0': No such file or directory
Adding this as a volume instead -v=/dev/tty0:/dev/tty0:rslave results in [seatd/seat.c:60] Could not open tty0 to update VT: Permission denied
Persisting user's permissions with --group-add=keep-groups + crun doesn't make a difference

Steps to reproduce the issue

Using OpenSuSE Tumbleweed (SystemD) as Host, I've added my main user to the correct groups in order to use --group-add=keep-groups (run.oci.keep_original_groups=1):

# HOST
$ sudo usermod -G video,render,audio,tty -a $USER
$ exec su -l $USER # Update groups without creating a subshell
$ groups
me tty wheel video render audio

For demonstration purposes I've created a rootless container which uses the root user inside of it. The same result can be observed if you use a regular user account inside the container and also if you don't specify --group-add=keep-groups:

# HOST
$ sudo zypper in -y crun podman
$ podman run \
  --replace --name=desktop-glx \
  --privileged --user=root:root --userns=keep-id --group-add=keep-groups --cap-add=ALL \
  --env-host --ipc=host --pid=host --ulimit=host --network=host --tz=local \
  --mount=type=devpts,destination=/dev/pts \
  --device /dev/dri \
  --device /dev/tty0 \
  -v=/dev/tty0:/dev/tty0:rslave \
  -v=$HOME:$HOME:rslave \
  -v=/run/dbus:/run/dbus:rslave \
  -v=/run/user:/run/user:rslave \
  -v=/run/systemd:/run/systemd:rslave \
  -v=/run/udev:/run/udev:rslave \
  -it \
  registry.opensuse.org/opensuse/tumbleweed:latest

# CONTAINER
$ zypper refresh && zypper dup -y
$ zypper in -y -t pattern sway
$ zypper in -y seatd
$ seatd -u $USER & sway -d
00:05:28.816 [common/terminal.c:149] Could not open target tty: Permission denied
00:05:28.816 [seatd/seat.c:60] Could not open tty0 to update VT: Permission denied
00:05:28.816 [common/terminal.c:149] Could not open target tty: Permission denied
00:05:28.816 [seatd/seat.c:71] Could not open terminal for VT 0: Permission denied
00:05:28.816 [seatd/seat.c:449] Could not open VT for client
00:05:28.816 [common/terminal.c:149] Could not open target tty: Permission denied
00:05:28.816 [seatd/seat.c:85] Could not open terminal to clean up VT 0: Permission denied
$ ls -ld /dev/tty0
crw--w---- 1 65534 65534 4, 0 Jun 10 09:05 /dev/tty0

I've verified that --group-add=keep-groups works correctly with crun:

# HOST
$ whoami
me
$ mkdir ~/test; chmod 0770 ~/test; sudo chown root:video ~/test
$ ls -ld ~/test
drwxrwx--- 1 root video 0 Jun 10 11:40 /home/me/test

$ ls -ld /dev/tty0
crw--w---- 1 root tty 4, 0 Jun 10 16:01 /dev/tty0

$ podman start desktop-glx
$ podman exec -it desktop-glx /bin/bash

# CONTAINER
$ touch /home/me/test/file # WORKS
$ ls -ld /home/me/test
drwxrwx--- 1 65534 65534 22 Jun 10 11:45 /home/me/test

Describe the results you received

Various scenarios for /dev/tty0

Doesn't exist when passed as a device
Exists when mounted as a volume but it's inaccessible due to permission issues which can't be worked around with --group-add=keep-groups

Describe the results you expected

Ability to access /dev/tty0

podman info output

host:
  arch: amd64
  buildahVersion: 1.30.0
  cgroupControllers:
  - cpu
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.7-1.3.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.7, commit: unknown'
  cpuUtilization:
    idlePercent: 99.92
    systemPercent: 0.03
    userPercent: 0.05
  cpus: 32
  databaseBackend: boltdb
  distribution:
    distribution: '"opensuse-tumbleweed"'
    version: "20230605"
  eventLogger: journald
  hostname: localhost.localdomain
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 6.3.4-1-default
  linkmode: dynamic
  logDriver: journald
  memFree: 63150395392
  memTotal: 67310841856
  networkBackend: cni
  ociRuntime:
    name: crun
    package: crun-1.8.3-1.1.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.3
      commit: 59f2beb7efb0d35611d5818fd0311883676f6f7e
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /etc/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-1.2.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: unknown
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 5
      libseccomp: 2.5.4
  swapFree: 0
  swapTotal: 0
  uptime: 4h 48m 48.00s (Approximately 0.17 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.opensuse.org
  - registry.suse.com
  - docker.io
store:
  configFile: /home/me/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/me/.local/share/containers/storage
  graphRootAllocated: 1999860994048
  graphRootUsed: 4332466176
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 2
  runRoot: /tmp/containers-user-1000/containers
  transientStore: false
  volumePath: /home/me/.local/share/containers/storage/volumes
version:
  APIVersion: 4.5.1
  Built: 1685318400
  BuiltTime: Mon May 29 02:00:00 2023
  GitCommit: ""
  GoVersion: go1.20.4
  Os: linux
  OsArch: linux/amd64
  Version: 4.5.1



### Podman in a container

No

### Privileged Or Rootless

Rootless

### Upstream Latest Release

Yes

### Additional environment details

Tested with
- Clean installation of `OpenSuSE Tumbleweed` and `OpenSuSE MicroOS` on bare metal, both uses SystemD.
- No SELinux
- No Apparmor

### Additional information

_No response_

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

GrabbenD · 2023-06-10T19:32:45Z

I've also tried removing --privileged and then adding --systemd=false to no avail.
Feels like I'm missing something?

For reference:

Sway works in Docker with almost identical commands from above (after removing incompatible parameters).

Same goes for rootful Podman containers, I was able to launch Sway just fine:

sudo podman run \
  --name=desktop-glx \
  --user=root:root --cap-add=ALL --security-opt label=disable \
  --ipc=host --pid=host --network=host \
  --device /dev/dri \
  --mount type=bind,src=/dev/tty0,target=/dev/tty0 \
  -v=/home/me:/home/me:rslave \
  -v=/run/dbus:/run/dbus:rslave \
  -v=/run/user:/run/user:rslave \
  -v=/run/systemd:/run/systemd:rslave \
  -v=/run/udev:/run/udev:rslave \
  -it \
  registry.opensuse.org/opensuse/tumbleweed:latest

Luap99 · 2023-06-12T09:09:16Z

If this is a regression please specify the last working version (and possibly even git bisect if you are able to do that).

rhatdan · 2023-06-12T09:21:54Z

Does sway work with rootful Podman?

@giuseppe PTAL

giuseppe · 2023-06-12T09:52:34Z

the same commands you've provided work well for me on Fedora 38.

Could it be something else blocking the access? AppArmor?

GrabbenD · 2023-06-12T10:15:13Z

Thanks for the assistance guys

If this is a regression please specify the last working version (and possibly even git bisect if you are able to do that).

@Luap99 I'm not sure if this ever worked in a rootless container. I noted it as a regression since Docker can access /dev/tty* with --privileged while Podman can't if you run Podman from a regular user account.

#15878

Does sway work with rootful Podman?

@rhatdan Yes, if I run Podman with sudo it works as expected, I don't even need --privileged

the same commands you've provided work well for me on Fedora 38.

@giuseppe Are you actually able to start Sway?

I can give Fedora a shot, did you use Fedora Server or Fedora Workstation?

Could it be something else blocking the access? AppArmor?

With OpenSuSE MicroOS and OpenSuSE Tumbleweed I've explicitly disabled SELinux and Apparmor during the installation:

# SELinux
$ sudo sestatus
bash: sestatus: command not found

$ sudo getenforce
bash: getenforce: command not found

# Apparmor
$ sudo less /sys/kernel/security/apparmor/profiles
/sys/kernel/security/apparmor/profiles: No such file or directory

$ sudo apparmor_status
apparmor module is loaded.
apparmor filesystem is not mounted.

$ sudo systemctl status apparmor
○ apparmor.service - Load AppArmor profiles
     Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; preset: enabled)
     Active: inactive (dead)
  Condition: start condition failed at Mon 2023-06-12 12:02:22 CEST; 8min ago

Luap99 · 2023-06-12T10:22:12Z

If this is a regression please specify the last working version (and possibly even git bisect if you are able to do that).

@Luap99 I'm not sure if this ever worked in a rootless container. I noted it as a regression since Docker can access /dev/tty* with --privileged while Podman can't if you run Podman from a regular user account.

Then it is not a regression for us, a regression means it worked in a previous version and then stopped working. Also docker runs as root by default unless you explicitly setup rootless docker.

giuseppe · 2023-06-12T11:17:34Z

the same commands you've provided work well for me on Fedora 38.

@giuseppe Are you actually able to start Sway?

yes, it starts. I am using Fedora Workstation 38

GrabbenD · 2023-06-12T14:22:18Z

yes, it starts. I am using Fedora Workstation 38

Great find @giuseppe!
I gave it a shot on bare metal:

Fedora Workstation 38

This uses GNOME 44 out of the box.
I was able to run Sway in a rootless Podman but only from the actual desktop environment/Gnome.
Seatd doesn't even have to be installed in the container. I believe this runs Sway in a nested window under Gnome's session manager in that case?

However, if I instead use tty2 I get:

[wlr] [backend/wayland/backend.c:555] Could not connect to remote display: Connection refused
[sway/server.c:73] Unable to create backend

For clarity:

$ ls -ld /dev/tty0
crw--w----. 1 root tty     4,  0 Jun 12 14:55 /dev/tty0

Fedora Server 38

This gives the same error as OpenSuSE Tumbleweed and OpenSuSE MicroOS: Could not open tty0 to update VT: Permission denied

$ ls -ld /dev/tty0
crw--w----. 1 root tty 4, 0 Jun 12 13:51 /dev/tty0

In this case, how can a rootless container be given permission to handle seats/tty0?

giuseppe · 2023-06-13T08:26:41Z

could be wayland to block the access?

GrabbenD · 2023-06-13T09:07:16Z

could be wayland to block the access?

Hmm @giuseppe, I can't find any indication why Wayland would be the cause. Outside of Podman Sway works fine on NixOS (which is a distro that runs installed packages in user space).

However, in Podman there's a check for tty0 which prohibits rootless containers from taking control if I understand the code correctly? #15878

podman/pkg/util/utils_linux.go

Lines 114 to 124 in 8d0fcd4

    
           			/* The following devices should not be mounted in rootless containers: 
        
           			 * 
        
           			 *   /dev/ptmx: The host-provided /dev/ptmx should not be shared to 
        
           			 *              the rootless containers for security reasons, and 
        
           			 *              the container runtime will create it for us 
        
           			 *              anyway (ln -s /dev/pts/ptmx /dev/ptmx); 
        
           			 *   /dev/tty and 
        
           			 *   /dev/tty[0-9]+: Prevent the container from taking over the host's 
        
           			 *                   virtual consoles, even when not in systemd mode 
        
           			 *                   for backwards compatibility. 
        
           			 */

GrabbenD · 2023-06-13T10:18:09Z

Just to clarify, Sway in Podman with:

rootfull-privileged & rootfull-unprivileged works.
rootless-privileged & rootless-unprivileged doesn't work.

giuseppe · 2023-06-13T10:19:26Z

the device should still be present in the container if you explicitly bind mount it through -v

GrabbenD · 2023-06-13T11:53:34Z

the device should still be present in the container if you explicitly bind mount it through -v

That makes sense @giuseppe but it's not accessible with either 🙁

-v=/dev/tty0:/dev/tty0
-v=/dev/tty0:/dev/tty0:rslave
--mount type=bind,src=/dev/tty0,target=/dev/tty0

Permission denied is the message from the system:
https://github.com/kennylevinsen/seatd/blob/master/seatd/seat.c#L58-L66

GrabbenD added the kind/bug Categorizes issue or PR as related to a bug. label Jun 10, 2023

GrabbenD changed the title ~~Unable to access /dev/tty0 in a rootless container~~ [Regression] Unable to access /dev/tty0 in a rootless container Jun 10, 2023

Luap99 changed the title ~~[Regression] Unable to access /dev/tty0 in a rootless container~~ Unable to access /dev/tty0 in a rootless container Jun 12, 2023

containers locked and limited conversation to collaborators Jun 13, 2023

giuseppe converted this issue into discussion #18870 Jun 13, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

This issue was moved to a discussion.

Unable to access /dev/tty0 in a rootless container #18845

Unable to access /dev/tty0 in a rootless container #18845

GrabbenD commented Jun 10, 2023 •

edited

Loading

GrabbenD commented Jun 10, 2023 •

edited

Loading

Luap99 commented Jun 12, 2023

rhatdan commented Jun 12, 2023

giuseppe commented Jun 12, 2023

GrabbenD commented Jun 12, 2023 •

edited

Loading

Luap99 commented Jun 12, 2023

giuseppe commented Jun 12, 2023

GrabbenD commented Jun 12, 2023 •

edited

Loading

giuseppe commented Jun 13, 2023

GrabbenD commented Jun 13, 2023 •

edited

Loading

GrabbenD commented Jun 13, 2023

giuseppe commented Jun 13, 2023

GrabbenD commented Jun 13, 2023 •

edited

Loading

This issue was moved to a discussion.

This issue was moved to a discussion.

Unable to access /dev/tty0 in a rootless container #18845

Unable to access /dev/tty0 in a rootless container #18845

Comments

GrabbenD commented Jun 10, 2023 • edited Loading

Issue Description

Steps to reproduce the issue

Describe the results you received

Describe the results you expected

podman info output

GrabbenD commented Jun 10, 2023 • edited Loading

Luap99 commented Jun 12, 2023

rhatdan commented Jun 12, 2023

giuseppe commented Jun 12, 2023

GrabbenD commented Jun 12, 2023 • edited Loading

Luap99 commented Jun 12, 2023

giuseppe commented Jun 12, 2023

GrabbenD commented Jun 12, 2023 • edited Loading

Fedora Workstation 38

Fedora Server 38

giuseppe commented Jun 13, 2023

GrabbenD commented Jun 13, 2023 • edited Loading

GrabbenD commented Jun 13, 2023

giuseppe commented Jun 13, 2023

GrabbenD commented Jun 13, 2023 • edited Loading

This issue was moved to a discussion.

GrabbenD commented Jun 10, 2023 •

edited

Loading

GrabbenD commented Jun 10, 2023 •

edited

Loading

GrabbenD commented Jun 12, 2023 •

edited

Loading

GrabbenD commented Jun 12, 2023 •

edited

Loading

GrabbenD commented Jun 13, 2023 •

edited

Loading

GrabbenD commented Jun 13, 2023 •

edited

Loading