This socket only uses a very primitive protocol, basically a single integer is
passed back and forth. So the confidentiality aspect is not really
problematic.

It has a DoS aspect, as pre-creating this path causes starting of fcitx to
fail.

There is no way to trick the daemon into making its interface accessible to
world. It uses a sequence like this:

    unlink(path);
    bind(path);
    chmod(path, 0600);

bind() always fails if the path already exists, thus pre-creating does not
work to trick this. If bind() fails then the daemon correctly stops processing
the remote API.

Although the chmod on the socket path is naive it should be save in this
context, since, if the bind() succeeded, the path must exist and be the socket
owned by the caller. No symlink attacks should be possible.

There is race condition also between bind() and chmod(), a time window, during
which the socket is visible with the default permissions. Unless there is an
insecure umask() set this should be no problem, though. A process calling
connect() on the socket needs write permissions on the socket. The default
umask will result in a socket with 0644 mode, thus other users than the
creator and root will not have connect() permission on the socket.

In summary, this fixed path only represents a local DoS vector, if another
user precreates this socket. Then fcitx cannot start. For reasons of
cleanliness I will try to get a patch into the package that places the socket
in $XDG_RUNTIME_DIR, if possible, or into $HOME, this will remove any
remaining worries there are.

Upstream has put fcitx major version 4 into maintenance mode. The codebase is
rather unclean is my feeling - there are error checks missing, the program
crashes easily with memory corruption. Upstream's recommendation is to switch
to fcitx major version 5 with a new architecture and backend libraries.

For this reason I won't involve upstream with this minor DoS issue. It should
be enough when we fix it in our packages.

Adding fcitx maintainers to keep them in the loop.

I will submit a path to the package soon to improve the security posture of
this package.

On top of this you could consider migrating the package to fcitx major version
5, since fcitx version 4 has been put into maintenance mode by upstream and
seems no longer supported.

I just submitted OBS sr#1105583 containing a patch to place this socket either
into $XDG_RUNTIME_DIR or into $HOME (as a hidden file). Once this is in
Factory this bug can be closed.

The patch for the socket path is now in Factory. Closing this as fixed.