Added scripts for Foxconn SDX55, Quectel EM120, and several old Sierra
Wireless manufactured devices:
* Installed but not used by default, the user needs to setup manual
links from ${pkgdatadir}/fcc-unlock.available.d, to
${pkgsysconfdir}/fcc-unlock.d in order to enable them.
* Installed with rights only for the owner, so that the dispatcher in
ModemManager can validate them.
* They rely on $PATH to find the qmicli/mbimcli tools.
In addition to these scripts, per-vid:pid links are created in the
same ${pkgdatadir}/fcc-unlock.available.d directory, specifying which
are the specific devices that require the FCC unlock operation.
This patch also creates the ${pkgsysconfdir}/fcc-unlock.d and
${pkglibdir}/fcc-unlock.d directories where ModemManager looks for the
enabled tools.
Note that the meson setup doesn't support creating/deleting links
officially yet, so we use a workaround using meson.add_install_script
that is not perfect (i.e. doesn't handle the symlink removal during
uninstall). See https://github.com/mesonbuild/meson/issues/1602
meson is a build system focused on speed an ease of use, which
helps speeding up the software development. This patch adds meson
support along autotools.
With the recently added support for modems using QRTR, ModemManager
needs to have access to the corresponding address family so it can
interact with the modem.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
This interface will provide support for the profile management
operations in different modem types.
This initial commit introduces support for the interface and provides
handlers for the methods that may be called in the interface.
GVfs' libgvfsdbus.so GIo module, when automatically loaded, attempts to
discover if there's a session D-Bus instance to use. It tries real hard
to get the socket name it would use -- in absence of XDG_RUNTIME_DIR it
decides to make it up with user's home directory. When HOME is unset
too, it just tries to figure it out by looking into /etc/passwd. Which
upsets SELinux that would better not see us looking into it.
We trigger the load of the GIo modules, by using the GFile API to access
the the ports in /dev. They're utterly uesless to us, but there doesn't
seem to be a way to disable their load. Oh well.
For now, let's just ensure HOME is set and the problematic path in glib
is not taken.
Instead of mixing both intltool and gettext, which not always work
correctly together, this patch obsoletes intltool and uses only
gettext, which includes support for translating XML files with ITS
rules.
See migration steps for GNOME projects here:
https://wiki.gnome.org/MigratingFromIntltoolToGettext
The gettext ITS rules for polkit policy files are imported from the
upstream polkit repository. We don't use the polkit-installed rule
files yet because there is no tagged release that contains those files
yet, so we cannot build-depend on any specific polkit version.
https://bugs.freedesktop.org/show_bug.cgi?id=96940
syslog implementations are using socket activation nowadays, so an
explicit ordering is not necessary anymore. Plus, syslog.target was
already dropped from systemd in v198.
Reported-by: Michael Biebl <biebl@debian.org>
What's left enabled:
* Access to /dev -- obviously
* CAP_SYS_ADMIN -- this is needed by TIOCSSERIAL only. Too bad this also
allows TIOCSTI, which allows for code injection unless something else
(SELinux) disallows access to ttys with shells.
Maybe kernel should use CAP_SYS_TTY_CONFIG for this.
* socket(AF_NETLINK) -- udev & kernel device changes
* socket(AF_UNIX) -- D-Bus
This commit enables a new core ModemManager daemon option, so that automatic
detection of available modems is totally disabled: '--no-auto-scan'. Note that
this option also replaces the previously used '--test-no-auto-scan' option,
which was only used during tests.
Along with the new ModemManager option, a new ReportKernelEvent() method in
the API is defined, which allows notifying the daemon of which interfaces it
should be accessing, as well as the main details of each interface. The only
mandatory parameters in the new method are 'action' (add/remove), 'name' (the
name of the interface) and 'subsystem' (the subsystem of the interface).
The mmcli tool has support for using the new api method via several new options:
* The '--report-kernel-event' option allows specifying device ports one by
one, and is a direct mapping of the ReportKernelEvent() method:
$ sudo mmcli --report-kernel-event="action=add,name=wwan0,subsystem=net"
$ sudo mmcli --report-kernel-event="action=add,name=cdc-wdm0,subsystem=usbmisc"
* The '--report-kernel-event-auto-scan' option uses udev monitoring to notify
events automatically to the daemon. This allows to operate in a way
equivalent to the default daemon operation (with implicit auto-scan).
Worth noting that the ReportKernelEvent() method is only usable when
'--no-auto-scan' is explicitly used in the daemon. An error will be reported if
the method is tried while standard udev monitoring is enabled (implicit if
auto scan isn't explicitly disabled in the daemon).
If mmcli is going to be used only to report 'real time' events, an optional
'--initial-kernel-events=[PATH]' may be given in the ModemManager call to
automatically process a set of port kernel events one by one on boot. The file
may e.g. contain:
action=add,name=wwan0,subsystem=net
action=add,name=cdc-wdm0,subsystem=usbmisc
By using:
<deny send_destination="org.freedesktop.ModemManager1"/>
..we prevent anyone on the system from sending us signals, even if we
subscribed to them. This is clearly not what this line intended. More
importantly, we silently break mm-auth-provider-polkit, as we never
receiver 'changed' signals via PolkitAuthority. Right now, this is not
required by the implementation of PolkitAuthority, but ModemManager
should not place restrictions on the implementation of external
libraries.
So make sure we only prevent Method-Calls to be sent to us. Any other
message that we didn't expect is automatically discarded by gdbus,
anyway.
Without this change, debugging dbus policies constantly shows messages
that Polkit couldn't send the 'changed' signal to ModemManager. This is
suppressed in non-debugging mode. But it would make debugging a lot
easier, if we'd avoid force-dropping those events and not clutter the
debug-log.
This reverts commit 91898aa8b0.
See additional comments in the following bug:
https://bugzilla.gnome.org/show_bug.cgi?id=701229
Basically, 'mask' and 'unmask' operations are not the ones we should be using
or suggesting; and the Alias= for the DBus file is the correct way to go.
The '--with-polkit' configure switch now supports more options than just yes
or no:
* strict: Active user needs to explicitly authenticate when peforming an
operation defined in the Device.Control, Messaging, Location or Contacts
interfaces. Polkit policy is set to 'auth_self_keep'.
* permissive: Active user doesn't need to explicitly authenticate when
peforming an operation defined in the Device.Control, Messaging, Location or
Contacts interfaces. Polkit policy is set to 'yes'.
* none: don't use polkit.
If '--with-polkit' is not given, usage will be automatically decided based on
the presence of the Polkit headers in the system (if headers found, strict
policy will be applied, otherwise none).
Also:
* '--with-polkit' is equivalent to '--with-polkit=strict'
* '--with-polkit=yes' is equivalent to '--with-polkit=strict'
* '--with-polkit=no' is equivalent to '--with-polkit=none'
* '--without-polkit' is equivalent to '--with-polkit=none'
By default, ModemManager will always apply the strict policy, in order to
protect the user from unwanted operations in the modem (e.g. getting the PIN
locked forever after wrong PIN/PUK unlock attempts).
https://bugzilla.gnome.org/show_bug.cgi?id=701740
Avoid setting up the Alias rule, which was a helper to let us 'disable' the
systemd service including dbus-activations. Without the Alias, 'disable' will
still let starting ModemManager through dbus-activation. If you really want to
fully disallow starting MM also through dbus-activation, you should 'mask' and
'unmask' the service.
E.g.:
$ sudo systemctl mask ModemManager
ln -s '/dev/null' '/etc/systemd/system/ModemManager.service'
$ sudo mmcli -L
error: couldn't find the ModemManager process in the bus
$ sudo systemctl unmask ModemManager
rm '/etc/systemd/system/ModemManager.service'
$ sudo mmcli -L
No modems were found
https://bugzilla.gnome.org/show_bug.cgi?id=701229
These diagrams are not expected to change much, so just include the generated
PNGs in the repository, and remove 'dia' from the prerequisites to build the
documentation.
