Dear Maintainer,

* What led up to the situation?

On a system with two users, the user who login as second cannot use the
opensnitch-ui.

* What exactly did you do (or not do) that was effective (or
  ineffective)?

- after start of the system
- login as user_one and use opensnitch-ui
- logout user_one
- login as user_two and start opensnitch-ui, it fails with

* What was the outcome of this action?

- the application fails direct at the start with

RuntimeError: Failed to bind to address unix:/tmp/osui.sock;

* What outcome did you expect instead?

- the application should start

* identicated reason is, the socket is create with access right
  of user_one, which prevents user_two to use the application

srwxrwxr-x 1 user_one user_one

Maybe the socket setting, mentioned in "man opensnitch-ui"

could be made the default.

cheers
Frank

I can confirm that version 1.6.8 still create the socket with the same
permissions:

  % ls -lah /tmp/osui.sock
  srw-r----- 1 pere pere 0 april 17 16:21 /tmp/osui.sock
  %

I had a look at some other distributions, and noticed in
<URL: https://github.com/getsolus/packages/tree/main/packages/o/opensnitch/ >
that solus uses a opensnitch group for socket access.  Perhaps an idea
for Debian too?  There are some patches there, I it would be even better
if these could be upstreamed first, to ensure consistent behaviour
across all Linux distributions.

I came across
<URL: https://github.com/evilsocket/opensnitch/issues/983 >, which
report that the UI is a server, so it is not really possible to run
several of them at the same time as different users.  This make me
believe that any changes to the socket setup in this system should be
cleared by the upstream developers.