I see that some snaps are trying to provide a web server on port 80 or 443. Examples are: Nextcloud, ONLYOFFICE and Fidus Writer (which I am working on). Yet I didn’t see any logic that deals with more than one package wanting to occupy port 80. Is the idea simply that we don’t worry about users trying to use the same port for several things? Or is there a general way to let the configure hook check whether port X is occupied and if so pick port Y instead?
Also, within the Fidus Writer snap we want to run a languagetool server. That server really only needs to be accessible from the Fidus Writer daemon. If I puck some random port (like: 8027) and do not give the languagetool daemon plugs for network and network-bind will that isolate it from everything else running on the machine? Will I still need to worry about port collision?
Snaps do not live within a separate network namespace so ports must be unique and are accessible to non-snaps and snaps that plug
network or are installed with
devmode confinement. If you do not give your snap the
network-bind plug then apparmor and seccomp will refuse to allow the application to listen on any sockets at all. That means even within your snap you’ll not be able to see the socket.
thanks for that. So yes, ports have to be unique, but how does one then make sure that only one package uses for example port 80? As far as I can tell, there is no logic around that. Everyone just tries to grab port 80 and the first package installed wins, right @lucyllewy?
Yes. If you try to have multiple processes listening on the same port things go south, with or without snaps.
I would expect a properly made snap to accept configuration via
snap set <snap> or allow the user to set the listen address manually in some file under
Right, ok. So it’s kind of the wild west and everyone just does whatever they want.
Sorry, this may have been obvious to others, but I thought maybe the system kept some kind of centralized list of what snaps get to use which ports, etc. . Now I know better.
IIRC snapd checks if a port is taken already (or was it systemd, I’m not sure) and will simply refuse to start the service, so it’s a matter of who comes first…
I don’t think that’s Snapd I think that’s systemd and only applies if everything is using ListenStream
I think you’re remembering systemd’s
.socket services, like
dbus.socket (although the dbus one listens on a named-socket rather than a network socket)
Also, with fine-grained network mediation, which is getting closer on the horizon, we will be in a position for snapd to manage and enforce which ports are requested/used.