Hey,
What should I have in my snapcraft.yaml in order to open a pair of pseudoterminal handles? I have experimented a bit with this and the master handle can open successfully, but the slave always return a bad file descriptor.
This used to work (perhaps a month ago) inside a .snap environment, but now no luck.
I looked through the interfaces, and tried a few, but nothing in there seems to fit my purpose…
Regards
Did no one understand the question, or does no one know the answer?
Technically this should just be possible, the launcher (snap-confine) creates /dev/pts/ptmx by default and you should be able to access it … perhaps @jdstrand has any deeper insight here ?
If I open a handle to that, not even the master handle is valid…
Ok, so I did some more debugging, thinking that the software code was the issue.
All ran fine outside of the .snap - and caused permission problems inside the .snap.
As it turned out, using the opengl plugin seems to have caused the issues.
Thanks for continuing to push on this and sorry for my late response (holiday, critical snapd issues). For posterity, I will point out that snap-confine sets up a devpts newinstance and adds /dev/tty, /dev/console and /dev/pts/ptmx to the device cgroup when the cgroup is in effect.
You mentioned something about the ‘opengl plugin’-- is this something specific to your application or did you mean to say ‘opengl snapd interface’ (which might indicate a snapd issue)?
Hey man,
I knew you would come around eventually! 
No harm, all is working fine atm.
What I meant to say was that the opengl snapd interface caused this issue.
More specifically: Simply by having it and not actually using it, which may be interesting.
Can you supply a small reproducer that demonstrates the issue? A C file or similar source code is fine. Please give the output of ‘snap version’ as well as indicate what distribution you are seeing the problem (eg, Ubuntu Core 16, 16.04 LTS, something else…). With that I can try to track this down.
Output of snap version is:
snap 2.28.5
snapd 2.28.5
series 16
ubuntu 17.04
kernel 4.10.0-38-generic
Testcase is hosted at: http://wikisend.com/download/608062/testcase.tar.gz
We should be allowed to upload stuffs here, within reasonable size…
Edit: Comment / Uncomment the “plugs” line, and you will see different output when running the snap.
Edit2: lsb_release -a:
Distributor ID: Ubuntu
Description: Ubuntu 17.04
Release: 17.04
Codename: zesty
Ok, this is more of the expanded udev tagging fallout. What is happening is that without connecting opengl, no devices are udev tagged and so no device cgroup is used for the snap. In 2.28+, the opengl interface udev tags a couple of devices and when the interface is connected, the /dev/pts/* slaves are not added to the cgroup. snap-confine needs to add this to the device cgroup unconditionally c 136:* rwm (unconditionally because we use a devpts newinstance, so this is safe).
This can be proven like so:
$ snap run --shell testcase
...$ testcase$SNAP/command-testcase.wrapper
open masterfd: Success
open slavedevice: Operation not permitted
# in another terminal
$ sudo sh -c "echo 'c 136:* rwm' > /sys/fs/cgroup/devices/snap.testcase.testcase/devices.allow"
# in the snap run --shell terminal
...$ $SNAP/command-testcase.wrapper
open masterfd: Success
open slavedevice: Success
We’ll get this fixed up for you. As for workarounds, you can use a devmode snap with core from the beta channel.
Thank you for reporting this!
Nice, Thank you!
I am very pleased.
FYI, https://github.com/snapcore/snapd/pull/4159. I also created https://github.com/snapcore/snapd/pull/4160 for 2.29, but not sure if it will make it in.