Use mkdtemp makes sure that IPC files are only visible to the
owning (client) process and do not use predictable names outside
of that.
This is not meant to be the last word on the subject, it's mainly a
simple way of making the current libqb more secure. Importantly, it's
backwards compatible with an old server.
It calls rmdir on the directory created by mkdtemp way too often, but
it seems to be the only way to be sure that things get cleaned up on
the various types of server/client exit. I'm sure we can come up with
something tidier for master but I hope this, or something similar, will
be OK for 1.0.x.
* memleak: ipc_socket: properly dispose local-scoped strndup values
Leaking memory was only possible when using filesystem sockets (see
use_filesystem_sockets function) and either:
- client is deliberately disconnecting from a server (continued run
imposes a risk of exhausting memory)
- server is deliberately disconnecting from its client (ditto, but
more substantial risk due to the common shared-resource nature
of the server)
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* memleak: ipc_socket: properly dispose inter-function strdup values
Leaking memory was only possible when the server accepted the client,
but didn't get (or was too shy) to talk to it prior to proceeding with
a disconnect.
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* ipc_socket: care to explain what's going on with file name inference
Related to the code parts at hand, there was an investigation/fix in
the past, initiated by "make check" failure on FreeBSD 9 [rhbz#1256701].
Unfortunately, not only the magic constant being modified was not
explained in 1908e6c, but (one can derive because of a lack of solid
background of what's going on here, which might have caused that),
it was modified incorrectly at one instance (see also [PR165 comment]),
which was then reinstated in 7ebcb3d.
So, finally de-mystify those magic constants. Also break the symmetry
between the client/server further with depending on the canonical
"request socket" alias at the server side (the former worked equally but
it was unnecessarily confusing and there's a risk this artificial alias
will get removed in the future).
[rhbz#1256701] https://bugzilla.redhat.com/1256701
[PR165 comment] https://github.com/ClusterLabs/libqb/issues/165#issuecomment-142949541
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
* IPC: Allow filesystem sockets to be chosen at run-time on Linux
Most of this patch came from Andrew Beekhof.
Keep a global variable that decides whether or not to use filesystem sockets
or abstract sockets for IPC connections. This variable is set by the presence of a file (default /etc/libqb/force-filesystem-sockets).
* tests: Fix test_ipcc_truncate_when_unlink_fails_shm test using FS sockets
When using filesystem sockets, the
test_ipcc_truncate_when_unlink_fails_shm test always fails, this was
because the unlink() call is wrapped to fail and so it never cleans up
the old version of the socket.
The fix is to preemptively remove the file before unlink gets wrapped.
* doc: Explain the force-filesystem-sockets option
Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
Set the sockets receive buffer size to match the send buffer. On
FreeBSD without this calls to sendto() will result in an ENOBUFS error
if the message is larger than net.local.dgram.recvspace sysctl.
* remove pid/euid from qb_ipcc_connection
* use proper #elif defines
* return NULL instead of 0 for pointers
* return -ENOMEM when malloc fails
* remove redundant if check
* use -1 for uid to chown()
When creating a unix socket it's default gid is that of the parent
directory. If the SOCKETDIR is owned by root:wheel with 1777 mode
some of the pacemaker daemons end up unable to communicate with one
another due to having insufficient permissions on the sockets.
This can be fixed by setting the client sockets gid to the primary
group of the server socket owner it's attempting to connect to. And,
on the server side by setting the gid to the already captured gid
stored in the connection info. This ensures that regardless of who
owns the socket directory, as long as the applications have r/w
access to it they should work.
When using sockets for IPC the file permissions default to whatever
the umask is. This isn't a problem on Linux since it uses abstract
namespace sockets which don't have any permissions, but on other
platforms this causes problems with pacemaker which spawns processes
under the hacluster user and ends up failing to connect.
Only one of the strndup calls should have subtracted 9 from
the name length. The other should have remained at 8.
Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
The code removed the last 8 characters of a socket name
to get the 'base name', but 9 are needed.
Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
In qb_ipcs_us_connect 4 files are created and bound.
I dont' know how this works for QB_LINUX or QB_CYGWIN.
But for the other OS the files are created and must be unlinked.
I use the same logic to construct the file names and unlink the files.
qb_ipcc_us_connect calls this
...
res = qb_ipc_dgram_sock_connect(r->response, "response", "request",
r->max_msg_size, &c->request.u.us.sock);
and qb_ipc_dgram_sock_connect calls
..
set_sock_addr
and in set_sock_addr the files are created if not Linux or Cygwin.
...
#if defined(QB_LINUX) || defined(QB_CYGWIN)
snprintf(address->sun_path + 1, UNIX_PATH_MAX - 1, "%s", socket_name);
#else
snprintf(address->sun_path, sizeof(address->sun_path), "%s/%s", SOCKETDIR,
socket_name);
#endif
...
We don't need to give the dispatch_add callback a reference
since the dispatch_del callback must occur before the
connection is destroyed. This extra reference counting
causes unnecessary complexity.
qb_ipcs_dispatch_connection_request is a callback function registered with
mainloop, or whatever other looping thread implementation is in use. When
this callback is registered, a reference of the connection object is given
to the mainloop thread. If this callback ever returns something none zero
the callback (and corresponding fd) is unregistered from the loop automatically,
so we must decrement the reference in this instance.
Since unregistering this callback from mainloop guarantees a disconnect
simply because requests on the fd are no longer processed, it is best
that we completely disconnect the connection (which will handle the unref)
when this callback returns an error... Otherwise since the fd is unregistered
from the mainloop thread, it may not be possible to detect a disconnect
in the future.
Seperate into a setup file and a socket backend file, it was getting messy
and confusing. Also preparing for using DGRAM sockets.
This should not result in any logical changes.
Signed-off-by: Angus Salkeld <asalkeld@redhat.com>
