[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

convention on listen port local or all network interfaces etc.

A convention on listen port local or all network interfaces etc. would
be desirable.

At the moment it looks like there is no convention for where server
applications are configured to listen by default, on localhost vs. all
interfaces. Looks like deciding that is up to the upstream author of the
software as well as the packager. Then it's up to the system
administrator to decide on where the server application should listen.
There is no great place for derivatives to globally modify this setting.

Usually applications using Tor ephemeral hidden services such as
ricochet-im, onionshare, ZeroNet, unMessage listen on localhost only.

Whonix is a Debian derivative with focus on anonymity, privacy and
security. To oversimplify it, we preconfigure Debian with these goals in

Due to Whonix's workstation, gateway split design, applications using
Tor ephemeral hidden services need to listen on the workstation's
external interface rather than on the workstation's localhost.

A global configuration file such as `/etc/ricochet-im.conf` works for
system administrators, but not for derivatives.

Why is a config folder `/etc/ricochet-im.d` strongly preferred over a
config file `/etc/ricochet-im.conf`? When a config file such as
`/etc/ricochet-im.conf` is owned by one package `ricochet-im`, it cannot
be owned by another package. If another package was to modify it using
`sed` or so, then dpkg would regard that file as user modified. The
problem is, next time that config file is changed by upstream, this
throws an interactive dpkg conflict resolution dialog at the user, which
is a usability bug. (example [x]) `sed` style config modifications are a
Debian policy violation as well.

So far we at Whonix had discussions with ricochet-im, onionshare,
ZeroNet and unMessage. They are all interested to make their
applications compatible with Whonix. However, asking each individual
project to `/etc/application-specific.d` folder where Whonix then could
drop a `/etc/application-specific.d/30_whonix.conf` that says
`listen=` is a lot duplicate effort and not that desirable
for these applications because they have not yet any need for

Having these applications auto detect Whonix also does not seem like
great solution. Seems unsafe. If the auto detection code kicks in as a
false positive, users would be at risk. Since it's Whonix specific and
general solutions reusable by anyone are to be preferred. At least that
is my interpretation of *nix philosophy.

May the following convention be suggested.

* Parse in lexical order.
** `/usr/lib/server-config.d`
** `/etc/server-config.d`
** `~/.config/server-config.d`
** Similar to how systemd would parse these folders. I.e. for example
start with parsing  `/usr/lib/server-config.d/30_default.conf`, followed
by `/usr/lib/server-config.d/31_other.conf`, followed by
`/etc/server-config.d/30_user.conf`, followed by
`/etc/server-config.d/40_user.conf` and so forth.
* The pseudo code in shell / bash:

for file_name in /usr/lib/server-config.d/*.conf ; do
   file_list="$file_list $file_name"

for file_name in /etc/server-config.d/*.conf ; do
   file_list="$file_list $file_name"

for file_name in /home/.config/server-config.d/*.conf ; do
   file_list="$file_list $file_name"

for item in $file_list ; do
   source "$item"

* config options:

# lines starting with # are ignored

# global fallback setting for all listeners

# web interfaces

# listen incoming IP

# optional application specific listen port


For example...

# /etc/server-config.d/30_default.conf

# /etc/server-config.d/50_user.conf

Would mean listen on `` as well as on ``.

This disable listeners by previous lower priority configuration files,
one could use `listen_ip=`. For example:

# /etc/server-config.d/30_default.conf

# /etc/server-config.d/50_user.conf

Would result in listening on `` only. This is similar to how
systemd parses systemd unit files.

To prevent different applications to parse the configuration
differently, to avoid unexpected results, it would be useful to have a
python library and command line tool to query it.

Any questions? Any suggestions? What do you think?


Reply to: