This convenience macro was created for the simple cases
where the length of the source string and the size of the
destination buffer can be figued out with strlen() and
sizeof() respectively, so we should use it wherever
possible instead of open-coding parts of it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Historically we matched log filters with strstr(), and when switching to
fnmatch in cbb0fd3c, it was stated that
we would continue to match substrings, with "foo" being equivalent to
"*foo*". Unfortuntely I forget to provide the code to actually make that
happen. This fixes it to prepend and append "*". We don't bother to
check if the pattern already has a leading/trailing '*', because
"**foo**" will match the same as "*foo*".
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Rather than specialcasing handling of the '*' character, use fnmatch()
to get normal shell wildcard syntax, as described in 'man glob(7)'.

To get an indication of the performance impact of using globs instead
of plain string matches, a test program was written. The list of all
260 log categories was extracted from the source. Then a typical log
filters setup was picked by creating an array of the strings "qemu",
"security", "util", "cgroup", "event", "object". Every filter string
was matched against every log category. Timing information showed that
using strstr() this took 8 microseconds, while fnmatch() took 114
microseconds.

IOW, fnmatch is 14 times slower than our existing strstr check. These
numbers show a worst case scenario that will never be hit, because it
is rare that every log category would have data output. The log category
matches are cached, so each category is only checked once no matter how
many log statements are emitted. IOW despite being slower, this will
be lost in the noise and have no consequence on real world logging
performance.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This reverts commit 8daa593b.

There are two undesirable aspects to the impl

  - Only a bare wildcard is permitted
  - The wildcard match is not performed in the order listed
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Since the introduction of log tuning capabilities to virt-admin by
@06b91785, this has been a much needed missing improvement on the way to
deprecate the global 'log_level'.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This was some copy-paste leftover.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Commit 9275def5 reduced the if block to one line without removing the
braces.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Ensure all enum cases are listed in switch statements.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The fix for CVE-2018-6764 introduced a potential deadlock scenario
that gets triggered by the NSS module when virGetHostname() calls
getaddrinfo to resolve the hostname:

 #0  0x00007f6e714b57e7 in futex_wait
 #1  futex_wait_simple
 #2  __pthread_once_slow
 #3  0x00007f6e71d16e7d in virOnce
 #4  0x00007f6e71d0997c in virLogInitialize
 #5  0x00007f6e71d0a09a in virLogVMessage
 #6  0x00007f6e71d09ffd in virLogMessage
 #7  0x00007f6e71d0db22 in virObjectNew
 #8  0x00007f6e71d0dbf1 in virObjectLockableNew
 #9  0x00007f6e71d0d3e5 in virMacMapNew
 #10 0x00007f6e71cdc50a in findLease
 #11 0x00007f6e71cdcc56 in _nss_libvirt_gethostbyname4_r
 #12 0x00007f6e724631fc in gaih_inet
 #13 0x00007f6e72464697 in __GI_getaddrinfo
 #14 0x00007f6e71d19e81 in virGetHostnameImpl
 #15 0x00007f6e71d1a057 in virGetHostnameQuiet
 #16 0x00007f6e71d09936 in virLogOnceInit
 #17 0x00007f6e71d09952 in virLogOnce
 #18 0x00007f6e714b5829 in __pthread_once_slow
 #19 0x00007f6e71d16e7d in virOnce
 #20 0x00007f6e71d0997c in virLogInitialize
 #21 0x00007f6e71d0a09a in virLogVMessage
 #22 0x00007f6e71d09ffd in virLogMessage
 #23 0x00007f6e71d0db22 in virObjectNew
 #24 0x00007f6e71d0dbf1 in virObjectLockableNew
 #25 0x00007f6e71d0d3e5 in virMacMapNew
 #26 0x00007f6e71cdc50a in findLease
 #27 0x00007f6e71cdc839 in _nss_libvirt_gethostbyname3_r
 #28 0x00007f6e71cdc724 in _nss_libvirt_gethostbyname2_r
 #29 0x00007f6e7248f72f in __gethostbyname2_r
 #30 0x00007f6e7248f494 in gethostbyname2
 #31 0x000056348c30c36d in hosts_keys
 #32 0x000056348c30b7d2 in main

Fortunately the extra stuff virGetHostname does is totally irrelevant to
the needs of the logging code, so we can just inline a call to the
native hostname() syscall directly.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Broken by 759b4d1b.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

At later point it might not be possible or even safe to use getaddrinfo(). It
can in turn result in a load of NSS module.

Notably, on a LXC container startup we may find ourselves with the guest
filesystem already having replaced the host one. Loading a NSS module
from the guest tree would allow a malicous guest to escape the
confinement of its container environment because libvirt will not yet
have locked it down.

Right-aligning backslashes when defining macros or using complex
commands in Makefiles looks cute, but as soon as any changes is
required to the code you end up with either distractingly broken
alignment or unnecessarily big diffs where most of the changes
are just pushing all backslashes a few characters to one side.

Generated using

  $ git grep -El '[[:blank:]][[:blank:]]\\$' | \
    grep -E '*\.([chx]|am|mk)$$' | \
    while read f; do \
      sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \
    done
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Commit 94c465d0 refactored the logging setup phase but introduced an
issue, where the daemon ignores verbose mode when there are no outputs
defined and the default must be used. The problem is that the default
output was determined too early, thus ignoring the potential '--verbose'
option taking effect. This patch postpones the creation of the default
output to the very last moment when nothing else can change. Since the
default output is only created during the init phase, it's safe to leave
the pointer as NULL for a while, but it will be set eventually, thus not
affecting runtime.
Patch also adjusts both the other daemons.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1442947Signed-off-by: NErik Skultety <eskultet@redhat.com>

With glibc >= 2.25.90 writev() is only available if you explicitly
include sys/uio.h. This matches the documented requirements, but
older glibc and other *NIX pulled in writev indirectly so the bug
wasn't noticed previously.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There was an unhandled 'open' call which resulted in:

"error: Library function returned error but did not set virError"

Even if this happens during the daemon's start when we still don't have
any set of outputs defined yet, we can safely report an error, since we
automatically fallback to stderr which is fine even for both
running as a daemonized process, since this happens before the daemon
forks into the background, and running as a systemd service, since
systemd re-directs std outputs to journald by default.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1436060Signed-off-by: NErik Skultety <eskultet@redhat.com>

Along with an empty string, it should also be possible for users to pass
NULL to the public APIs which in turn would trigger a routine(future
work) responsible for defining an appropriate default logging output
given the current circumstances.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

These helpers will manage the log destination defaults (fetch/set). The reason
for this is to stay consistent with the current daemon's behaviour with respect
to /etc/libvirt/<daemon>.conf file, since both assignment of an empty string
or not setting the log output variable at all trigger the daemon's decision on
the default log destination which depends on whether the daemon runs daemonized
or not.
This patch also changes the logic of the selection of the default
logging output compared to how it is done now. The main difference though is
that we should only really care if we're running daemonized or not, disregarding
the fact of (not) having a TTY completely (introduced by commit eba36a38) as
that should be of the libvirtd's parent concern (what FD it will pass to it).

 Before:
 if (godaemon || !hasTTY):
     if (journald):
         use journald

 if (godaemon):
     if (privileged):
         use SYSCONFIG/libvirtd.log
     else:
         use XDG_CONFIG_HOME/libvirtd.log
 else:
     use stderr

 After:
 if (godaemon):
     if (journald):
         use journald

     else:
         if (privileged):
             use SYSCONFIG/libvirtd.log
         else:
             use XDG_CONFIG_HOME/libvirtd.log
 else:
     use stderr
Signed-off-by: NErik Skultety <eskultet@redhat.com>

We have couple of functions that operate over NULL terminated
lits of strings. However, our naming sucks:

virStringJoin
virStringFreeList
virStringFreeListCount
virStringArrayHasString
virStringGetFirstWithPrefix

We can do better:

virStringListJoin
virStringListFree
virStringListFreeCount
virStringListHasString
virStringListGetFirstWithPrefix
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Not every system out there has syslog, that's why we check for it
in our configure script. However, in 640b58ab while fixing
another issue, some variables and functions are called that are
defined only when syslog.h is present. But these function
calls/variables were not guarded by #ifdef-s.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In both virLogParseOutput and virLogParseFilter, rather than returning
NULL, goto cleanup since it's possible that for each the first condition
passes, but the || condition doesn't and thus we leak memory.

Handling of outputs and filters has been changed in a way that splits
parsing and defining. Do the same thing for logging priority as well, this
however, doesn't need much of a preparation.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This is mainly virLogAddOutputTo* which were replaced by virLogNewOutputTo* and
the previously poorly named ones virLogParseAndDefine* functions. All of these
are unnecessary now, since all the original callers were transparently switched
to the new model of separate parsing and defining logic.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Similar to outputs, parser should do parsing only, thus the 'define' logic
is going to be stripped from virLogParseAndDefineFilters by replacing calls to
this method to virLogSetFilters instead.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Since virLogParseAndDefineOutputs is going to be stripped from 'output defining'
logic, replace all relevant occurrences with virLogSetOutputs call to make the
change transparent to all original callers (daemons mostly).
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This method will eventually replace virLogParseAndDefineFilters which
currently does both parsing and defining.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This API is the entry point to output modification of the logger. Currently,
everything is done by virLogParseAndDefineOutputs. Parsing and defining will be
split into two operations both handled by this method transparently.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Abstraction added over parsing a single filter. The method parses potentially a
set of logging filters, while adding each filter logging object to a
caller-provided array.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Another abstraction added on the top of parsing a single logging output. This
method takes and parses the whole set of outputs, adding each single output
that has already been parsed into a caller-provided array. If the user-supplied
string contained duplicate outputs, only the last occurrence is taken into
account (all the others are removed from the list), so we silently avoid
duplicate logs.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Same as for outputs, introduce a new method, that is basically the same as
virLogParseAndDefineFilter with the difference that it does not define the
filter. It rather returns a newly created object that needs to be inserted into
a list and then defined separately.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Introduce a method to parse an individual logging output. The difference
compared to the virLogParseAndDefineOutput is that this method does not define
the output, instead it makes use of the virLogNewOutputTo* methods introduced
in the previous patch and just returns the virLogOutput object that has to be
added to a list of object which then can be defined as a whole via
virLogDefineOutputs. The idea remains still the same - split parsing and
defining of the logging primitives (outputs, filters).
Additionally, since virLogNewOutputTo* methods are now finally used,
ATTRIBUTE_UNUSED can be successfully removed from the methods' definitions,
since that was just to avoid compiler complaints about unused static functions.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Now that we're in the critical section, syslog connection can be re-opened
by issuing openlog, which is something that cannot be done beforehand, since
syslog keeps its file descriptor private and changing the tag earlier might
introduce a log inconsistency if something went wrong with preparing a new set
of logging outputs in order to replace the existing one.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Continuing with the effort to split output parsing and defining, these new
functions return a logging object reference instead of defining the output.
Eventually, these functions will replace the existing ones (virLogAddOutputTo*)
which will then be dropped.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Prepare a method that only defines a set of filters. It takes a list of
filters, preferably created by virLogParseFilters. The original set of filters
is reset and replaced by the new user-provided set of filters.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Prepare a method that only defines a set of outputs. It takes a list of
outputs, preferably created by virLogParseOutputs. The original set of outputs
is reset and replaced by the new user-provided set of outputs.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Outputs are a bit trickier than filters, since the user(config)-specified
set of outputs can contain duplicates. That would lead to logging the same
message twice. For compatibility reasons, we cannot just error out and forbid
the daemon to start if we find duplicate outputs which do not make sense.
Instead, we could silently take into account only the last occurrence of the
duplicate output and remove all the previous ones, so that the logger will not
try to use them when it is looping over all of its registered outputs.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

This method allocates a new filter object which it then returns back to caller.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

In order to later split output parsing and output defining, introduce a new
function which will create a new virLogOutput object which the parser will
insert into a list with the list being eventually defined.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

There is really no reason why we could not keep journald's fd within the
journald output object the same way as we do for regular file-based outputs.
By doing this we later won't have to special case the journald-based output
(due to the fd being globally shared) when replacing the existing set of outputs
with a new one. Additionally, by making this change, we don't need the
virLogCloseJournald routine anymore, plain virLogCloseFd will suffice.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Right now virLogParse* functions are doing both parsing and defining of filters
and outputs which should be two separate operations. Since the naming is
apparently a bit poor this patch renames these functions to
virLogParseAndDefine* which eventually will be replaced by virLogSet*.
Additionally, virLogParse{Filter,Output} will be later (after the split) reused,
so that these functions do exactly what the their name suggests.
Signed-off-by: NErik Skultety <eskultet@redhat.com>