libnm-core/nm-vpn-plugin-info.c: In function ‘nm_vpn_plugin_info_get_auth_dialog’:
shared/gsystem-local-alloc.h:53:46: error: ‘prog_basename’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
Fixes: a3f94f451b
In commit ca000cffbb, we changed to
accept a plugin library name without path. One reason for that
is to keep architecture dependent parts out of the .name file
and possibly support multilib.
However, the shared libraries of VPN plugins are not installed in
a global library search path, but for example into
"/usr/lib64/NetworkManager/libnm-vpn-plugin-openvpn.so".
In that case, specifying "plugin=libnm-vpn-plugin-openvpn.so"
would not be enough to find plugin.
Instead, when configuring a plugin name without path, assume
it is in NMPLUGINDIR directory. Modify nm_vpn_editor_plugin_load_from_file()
to allow path-less plugin-names. Previously such names would be rejected
as not being absolute. This API allows to do file verification
before loading the plugin, but it now supports prepending NMPLUGINDIR
to the plugin name. Basically, this function mangles the plugin_name
argument and checks that such a file exists.
The recently added nm_vpn_editor_plugin_load() continues to behave
as before: it does no checks whatsoever and passes the name directly
to dlopen(). That way, it uses system search paths like LD_LIBRARY_PATH
and performs no checks on the file.
Fixes: ca000cffbb
Since commit 3dfbbb227e, we enforce that
the plugin path in the .name file is absolute and we perform several
checks on the file before loading it (ownership, etc).
Relax that, to also allow libray names without path component.
In that case, g_module_open()/dlopen() will search for a library
in various search paths. This allows, to omit absolute paths
in the .name file. The latter is problematic, because by default
we install the .name file in the architecture independent location
/usr/lib/NetworkManager. As such, it should not contain paths
to architecture dependent libraries. With this change, a .name
file can contain only the library name and it will be loaded
using the usual mechanism.
However, specifying absolute paths is still possible and works
same as before, including checking file permissions.
As such, distributions probably should package the VPN plugins
to have no path in the .name file. On the other hand, a user
compiling from source probably wants to specify an absolute
path. The reason is, that the user probably doesn't build the
plugin for multiple achitectures and that way, he can install
the plugin in a separate (private) prefix.
Instead of looking into the keyfile, lookup the "supports-multiple-connections" setting
in the "keys" hash. This has some behavioral difference:
- g_key_file_get_boolean() first does g_key_file_get_value(), and then
converts the string using the private g_key_file_parse_value_as_boolean()
function -- which is case-sensitive, accepts "true|false|0|1" and
considers only the text until the first whitespace.
- now, we put g_key_file_get_string() into the cache "keys" and
parse it with _nm_utils_ascii_str_to_bool(). The latter is
case insensitive, allows also "yes|no|on|off", strips whitespaces.
However, the difference is subtle and shouldn't matter.
The point of this change is to free "keyfile" after construction.
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
- "gsystem-local-alloc.h" and <gio/gio.h> are already included via
"nm-default.h". No need to include them separately.
- include "nm-macros-internal.h" via "nm-default.h" and drop all
explict includes.
- in the modified files, ensure that we always include "config.h"
and "nm-default.h" first. As second, include the header file
for the current source file (if applicable). Then follow external
includes and finally internal nm includes.
- include nm headers inside source code files with quotes
- internal header files don't need to include default headers.
They can savely assume that "nm-default.h" is already included
and with it glib, nm-glib.h, nm-macros-internal.h, etc.
It is not used externally and its use might be confusing and undesired when we
add plugin aliases. The external users should only use the name when idenfiying
the plugin and nm_vpn_plugin_info_list_find_by_service() when matchin the plugin.
A separate instance of the support plugin is spawned for each connection with
a different bus name. The bus name is passed via --bus-name <name> argument.
Plugins that support the feature indicate it with
support-multiple-connections=true key in the [VPN Connection] section.
The bus name is currently generated by adding a .<connection.uuid> to the VPN
service name. It's guarranteed unique, but if it proves to be too long or ugly
it can easily be replaced with something more meaningful (such as the same number
as is used for connection's DBus name).
NMVpnService has been removed and folded into NMVpnConnection. A
NMVpnConnection will spawn a service plugin instance whenever it is activated
and notices the bus name it needs is not provided.
The NMVpnManager no longer needs to keep track of the connections in use apart
for compatibility purposes with plugins that don't support the feature.
The localization headers are now included via "nm-default.h".
Also fixes several places, where we wrongly included <glib/gi18n-lib.h>
instead of <glib/gi18n.h>. For example under "clients/" directory.
NMVpnPluginInfo is little more then a wrapper around
the GKeyFile that describes the VPN plugin settings,
i.e. the name files under "/etc/NetworkManager/VPN/".
Add this class to make the VPN API more explicit. Clients
now can use NMVpnPluginInfo instead of concerning themselves
with loading the keyfile and the meaning of its properties.
Also add support for a new VPN plugins directory
"/usr/lib/NetworkManager/VPN", which should replace
"/etc/NetworkManager/VPN" in the future. But we have to
consider both locations for backward compatibility.
The content of the VPN directory is not user configuration,
hence it should not be under "/etc". See related bug 738853.
