Bug#988060: barrier: misleading error when too many open files

[Phil Endecott]

The reason for the too-many-open-files appears to be that 
sockets are leaked when client connections fail due to SSL 
errors.

The particular SSL error in my case seemed to be due to the 
server certificate having expired. Barrier seems to automagically 
create SSL certs that are valid for one year.

I have been starting the Barrier server from my .config/openbox/autostart :
barriers -c /home/phil/.synergy.conf --enable-crypto

It appears that that doesn't do anything about expired SSL 
certs. On the other hand, if I start the barrier GUI:
$ barrier --no-tray

then something does seem to create a certificate - at least, 
it did when I removed the expired cert; I'm not sure if it 
actually checks the expiry date. (Looking at the source the 
only attempt to generate certs is in the GUI code, but I'm 
not sure if that is run on expiry or only if no cert exists.)

In summary there are three issues here:

1. Misleading error reporting on server when too-many-open-files 
prevents the SSL certificate file from being read.

2. Server socket leak when SSL error (certificate expired?) causes 
client connection to fail.

3. Server SSL certificate expiry does not seem to be handled when 
barriers is invoked directly, rather than the barrier GUI; it does 
not attempt to generate new certificates, nor does it report any 
useful error about expired certs to syslog when client connections 
fail. (Nor do clients when they receive expired certs.)


Thanks, Phil.

Bug#988060: barrier: misleading error when too many open files

[Phil Endecott]

Package: barrier
Version: 2.1.2+dfsg-1~bpo9+1
Severity: normal

Dear Maintainer,

I have Barrier server version 2.1.2+dfsg-1~bpo9+1 on a Debian box 
and Barrier client version 2.3.3 on a Mac (from Homebrew).

After restarting the Mac, Barrier failed to start. Its log says 
repeatedly:

ERROR: ssl error occurred (system call failure)
ERROR: failed to connect to secure socket

On the Debian system, syslog shows:

ERROR: ssl certificate doesn't exist: 
/home/phil/.local/share/barrier/SSL/Barrier.pem

But that file does exist:

-rw--- 1 phil phil 2798 Feb 20  2020 
/home/phil/.local/share/barrier/SSL/Barrier.pem

Investigating with strace:

[pid 15729] openat(AT_FDCWD, "/home/phil/.local/share/barrier/SSL/Barrier.pem", 
O_RDONLY) = -1 EMFILE (Too many open files)

So there appears to be an issue with misleading error reporting.

Looking at the source:
https://github.com/debauchee/barrier/blob/master/src/lib/net/SecureSocket.cpp
Line 344
It just checks std::ifstream::good().

At the very minimum, the error message "ssl certificate doesn't exist" 
should be replaced with "ssl certificate file could not be opened". 
Much better, it should use errno and e.g. strerror to give a useful 
message.

(Note I'm using an older version of Barrier but I'm looking at the 
current source code.)

I'm continuing to look at what the underlying issue might be.


-- System Information:
Debian Release: 9.9
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 3.14.29+ (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages barrier depends on:
ii  libavahi-compat-libdnssd1  0.7-4+b1
ii  libc6  2.28-10
ii  libcurl3   7.52.1-5+deb9u9
ii  libgcc11:6.3.0-18+deb9u1
ii  libice62:1.0.9-2
ii  libqt5core5a   5.7.1+dfsg-3+deb9u1
ii  libqt5gui5 5.7.1+dfsg-3+deb9u1
ii  libqt5network5 5.7.1+dfsg-3+deb9u1
ii  libqt5widgets5 5.7.1+dfsg-3+deb9u1
ii  libsm6 2:1.2.2-1+b3
ii  libssl1.1  1.1.0k-1~deb9u1
ii  libstdc++6 6.3.0-18+deb9u1
ii  libx11-6   2:1.6.4-3+deb9u1
ii  libxext6   2:1.3.3-1+b2
ii  libxi6 2:1.7.9-1
ii  libxinerama1   2:1.1.3-1+b3
ii  libxrandr2 2:1.5.1-1
ii  libxtst6   2:1.2.3-1
ii  openssl1.1.0k-1~deb9u1

barrier recommends no packages.

barrier suggests no packages.

-- no debconf information