Snap interfaces serial-port error "serial-port path attribute must be a valid device node"

snapd
1

The demo snap have slots interface:serial-port
slots:
serial-ttygps:
interface: serial-port
path: /dev/ttyGPS

after i install the demo snap,error is “2020-01-06T08:29:22Z INFO snap “demo” has bad plugs or slots: serial-ttygps (serial-port path attribute must be a valid device nod”

$ sudo snap install --dangerous /tmp/demo_0.1_armhf.snap
2020-01-06T08:29:22Z INFO snap “demo” has bad plugs or slots: serial-ttygps (serial-port path attribute must be a valid device node)
demo 0.1 installed
$
$
$ ls /dev/ttyGPS -l
lrwxrwxrwx 1 root root 11 Jan 1 1970 /dev/ttyGPS -> /dev/ttyLP1
$
$
how to fix interface:serial-port error? thanks

1 Like
2

The current pattern is described as follows here:

It’s easy enough to add a rule to allow /dev/ttyGPS or /dev/ttyLP1, but I’m not familiar with those device nodes never having seen them before. Are /dev/ttyGPS and /dev/ttyLP1 device nodes specific to your model/board or this is a generic access? I couldn’t find any reference to /dev/ttyGPS from some simple searching (and nothing in https://www.kernel.org/doc/Documentation/admin-guide/devices.txt), but I saw some references to /dev/ttyLP* in other random searches.

3

thanks for reply. the /dev/ttyGPS is specific to my iot device.
In fact i want to use serial-port for virtual port, such as /dev/tttyCOM1(/dev/pts/0)
image

if add the seial-port path with “/dev/ttyCOM1” or “/dev/ptx/0” ,there are all error for “serial-port path attribute must be a valid device node”

the seial-port path must be the format you mentioned？

whether the serial-port can support virtual port /dev/pts/x ?

5

the serial port interface is sadly restricted to exactly the regex that ian quoted above:

var serialDeviceNodePattern = regexp.MustCompile("^/dev/tty(mxc|USB|ACM|AMA|XRUSB|S|O)[0-9]+$")

anything not matching this pattern will be refused, if you want something like “COM” or “GPS” supported, it needs to be added to this pattern, similar to this patch:

https://github.com/snapcore/snapd/pull/3256

in case your devices are USB based there is also the serial hotplug feature now:

6

So I think at this point our options to add to the serial-port interface are:

  • add /dev/ttyGPS
  • add /dev/ttyCOM[0-9]+
  • add /dev/ttyLP[0-9]+

I don’t feel comfortable adding /dev/pts/[0-9]+ because that’s not guaranteed to be a serial-port, but perhaps this is fine. I think the psuedo tty system is a bit messy which is why I personally feel hesitant about this, but that’s just my feel.

@jdstrand what are your thoughts on expanding the serial-port device node pattern to allow this use case?

7

snapd supports pseudo-terminals via /dev/pts via devpts with access to /dev/pts/* available via openpty() and working with /dev/ptmx (eg, https://github.com/snapcore/snapd/pull/4160/files). @pangda - can you provide a working reproducer for how you are setting up and accessing the pts devices?

8

IIUC this support in snapd is for snapd to create snap-private devpts instances, not to access dev/pts outside of the snap (which is what would be happening with this symlink /dev/ttyCOM1 -> /dev/pts/0 that is referenced above), is that correct?

9

It depends where the symlink was created. If it was outside the snap, then I wouldn’t expect that to work.

10

Hi all, thanks for reply, i have tested the ‘serial-port’ interfaces, there are only valid serial-port path (("^/dev/tty(mxc|USB|ACM|AMA|XRUSB|S|O)[0-9]+$")) need to add ‘serial-port’ interfaces, other serial-port path such as /dev/ttyGPS or /dev/ttyCOM1 is not need to add ‘serial-port’ interface for snap sandbox security.