Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Wrong owner in /dev/pts #1016

Closed
Gavus opened this issue Feb 25, 2022 · 10 comments
Closed

Wrong owner in /dev/pts #1016

Gavus opened this issue Feb 25, 2022 · 10 comments
Labels
1. Bug Something isn't working

Comments

@Gavus
Copy link

Gavus commented Feb 25, 2022 •
edited
Loading

Describe the bug
My /dev/pts/ inside a toolbox have the owner set as root. Outside of toolbox they are owned by my user.

Steps how to reproduce the behaviour

  1. Enter a running toolbox with at least two sessions.
  2. Start python3.
  3. Enter: "import io; tty=io.TextIOWrapper(open("/dev/pts/x", "r+b", buffering=0))" (replace x with one of the session numbers).

Expected behaviour
No error.

Actual behaviour
"PermissionError: [Errno 13] Permission denied: '/dev/pts/x'.

Output of toolbox --version (v0.0.90+)
toolbox version 0.0.99.3

Toolbox package info (Github)
tag 0.0.99.3

Output of podman version
e.g.,

Version:            3.0.1
RemoteAPI Version: ?
Go Version:         ?
OS/Arch:            linux/amd64
``

**Info about your OS**
Debian 11 (bullseye)

**Additional context**
I noticed this problem when using the python debugger module pudb, wanting to display the tui in another terminal.
@Gavus Gavus added the 1. Bug Something isn't working label Feb 25, 2022
@Ramblurr
Copy link

Ramblurr commented Dec 8, 2022 •
edited
Loading

This also prevents the use of emacsclient --tty:

$ emacsclient --tty
*ERROR*: Could not open file: /dev/pts/1
$ sudo chown ramblurr /dev/pts/1
$ emacsclient --tty
<emacs opens>

For my system:

toolbox --version
toolbox version 0.0.99.3

podman version
Client:       Podman Engine
Version:      4.3.1
API Version:  4.3.1
Go Version:   go1.19.2
Built:        Fri Nov 11 16:01:27 2022
OS/Arch:      linux/amd64
  • OS: Fedora Silverblue 37
  • podman package: podman-4.3.1-1.fc37.x86_64
  • toolbox package: toolbox-0.0.99.3-7.fc37.x86_64

@swick
Copy link
Contributor

swick commented Feb 20, 2023

This also prevents the mutter kvm test suit from running:

qemu-system-x86_64: -chardev file,id=console,path=/proc/self/fd/2

@debarshiray

This was referenced Mar 2, 2023
Closed
Open
Closed
@debarshiray
Copy link
Member

I filed containers/crun#1158 for some clarifications and advice.

debarshiray added a commit to debarshiray/toolbox that referenced this issue Mar 7, 2023
@debarshiray
cmd/create, cmd/initContainer: Mount the devpts file system at runtime
0953dc4 
Anything that's specified during 'podman create ...' gets statically
baked into the container's configuration, and is either difficult or
impossible to change afterwards.  This means that Toolbx containers
created with older versions of Toolbx keep diverging from those created
with newer versions.  Hence, making it complicated to keep older
containers working with newer Toolbx.

Mounting the devpts file system at runtime as part of the Toolbx
container's entry point will make it possible to update the attributes
of the mount, if necessary, for both existing and newly created
containers.

For what it's worth, this does alter the mount options by removing
'context'.

With 'podman create --mount type=devpts,destination=/dev/pts' it was:
  $ mount | grep
  ...
  devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,
    context="system_u:object_r:container_file_t:s0:c1022,c1023",
    gid=100005,mode=620,ptmxmode=666)

Now with 'mount -t devpts -o noexec,nosuid,gid=5,mode=620,ptmxmode=666'
it is:
  $ mount | grep
  devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,
    gid=100005,mode=620,ptmxmode=666)

containers#1016
@debarshiray debarshiray mentioned this issue Mar 7, 2023
Open
debarshiray added a commit to debarshiray/toolbox that referenced this issue Mar 7, 2023
@debarshiray
cmd/create, cmd/initContainer: Mount the devpts file system at runtime
0e68dc9 
Anything that's specified during 'podman create ...' gets statically
baked into the container's configuration, and is either difficult or
impossible to change afterwards.  This means that Toolbx containers
created with older versions of Toolbx keep diverging from those created
with newer versions.  Hence, making it complicated to keep older
containers working with newer Toolbx.

Mounting the devpts file system at runtime as part of the Toolbx
container's entry point will make it possible to update the attributes
of the mount, if necessary, for both existing and newly created
containers.

For what it's worth, this does alter the mount options by removing
'context'.

With 'podman create --mount type=devpts,destination=/dev/pts' it was:
  $ mount | grep
  ...
  devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,
    context="system_u:object_r:container_file_t:s0:c1022,c1023",
    gid=100005,mode=620,ptmxmode=666)

Now with 'mount -t devpts -o noexec,nosuid,gid=5,mode=620,ptmxmode=666'
it is:
  $ mount | grep
  devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,
    gid=100005,mode=620,ptmxmode=666)

containers#1016
debarshiray added a commit to debarshiray/toolbox that referenced this issue Mar 7, 2023
@debarshiray
cmd/create, cmd/initContainer: Mount the devpts file system at runtime
cf6db37 
Anything that's specified during 'podman create ...' gets statically
baked into the container's configuration, and is either difficult or
impossible to change afterwards.  This means that Toolbx containers
created with older versions of Toolbx keep diverging from those created
with newer versions.  Hence, making it complicated to keep older
containers working with newer Toolbx.

Mounting the devpts file system at runtime as part of the Toolbx
container's entry point will make it possible to update the attributes
of the mount, if necessary, for both existing and newly created
containers.

For what it's worth, this does alter the mount options by removing
'context'.

With 'podman create --mount type=devpts,destination=/dev/pts' it was:
  $ mount | grep
  ...
  devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,
    context="system_u:object_r:container_file_t:s0:c1022,c1023",
    gid=100005,mode=620,ptmxmode=666)

Now with 'mount -t devpts -o noexec,nosuid,gid=5,mode=620,ptmxmode=666'
it is:
  $ mount | grep
  devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,
    gid=100005,mode=620,ptmxmode=666)

containers#1016
@debarshiray
Copy link
Member

I filed containers/podman#17701 for some clarifications and advice.

That got renamed to containers/crun#1158

@debarshiray
Copy link
Member

The original problem reported with Python does appear to be solved by PR containers/crun#1159 that's linked from the above podman/crun issue:

⬢[rishi@toolbox ~]$ tty
/dev/pts/0
⬢[rishi@toolbox ~]$ 
⬢[rishi@toolbox ~]$ ls -l /dev/pts
total 0
crw--w----. 1 rishi tty  136, 0 Mar  8 21:21 0
crw-rw-rw-. 1 root  root   5, 2 Mar  8 21:07 ptmx
⬢[rishi@toolbox ~]$ 
⬢[rishi@toolbox ~]$ python3
Python 3.10.8 (main, Nov 14 2022, 00:00:00) [GCC 12.2.1 20220819 (Red Hat 12.2.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import io; tty=io.TextIOWrapper(open("/dev/pts/0", "r+b", buffering=0))
>>>

@debarshiray
Copy link
Member

This also prevents the use of emacsclient --tty:

$ emacsclient --tty
*ERROR*: Could not open file: /dev/pts/1
$ sudo chown ramblurr /dev/pts/1
$ emacsclient --tty
<emacs opens>

I suspect that this is similar to the problem @dustymabe has been facing with gpg-agent and pinentry in #568

Even if you fix the user ownership of the pseudo-terminal device (ie., the output of tty(1)), running emacsclient --tty inside the container doesn't open Emacs in the same terminal. Instead it opens it on a different host terminal whose tty(1) accidentally happens to match the container's.

I use Emacs, but not in a server-client mode, so I am not entirely sure, but I think that the client should open in the same terminal where I typed emacsclient --tty. At least that's what happens on the host.

It's an accident because the pseudo-terminal devices inside the container aren't the same as on the host. They are totally different because the container has it's own devpts file system at /dev/pts within its mount and user namespaces.

@debarshiray
Copy link
Member

This also prevents the mutter kvm test suit from running:

qemu-system-x86_64: -chardev file,id=console,path=/proc/self/fd/2

Does containers/crun#1159 help?

I can try to run the mutter test suite myself, but it will take some time. :)

@swick
Copy link
Contributor

swick commented Mar 8, 2023

Always fun to test stuff like this on silverblue. Yes, works like a charm. Thanks!

@debarshiray
Copy link
Member

Always fun to test stuff like this on silverblue. Yes, works like a charm. Thanks!

Yes, I can imagine. I locally rebuild the RPM with the relevant patch and force it onto my base image. :P

Thanks for testing it, @swick !

@debarshiray
Copy link
Member

I am closing this on the assumption that the emacsclient --tty problem is unrelated to the other two problems reported here.

Please leave a comment or open an issue if you have reason to believe otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
1. Bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@Ramblurr @swick @debarshiray @Gavus