The previous version only worked on Fedora-like distributions which have
`libdir = /usr/lib{,64}`. On multi-arch Debian systems, it would
calculate `pamlibdir = /usr/x86_64-linux-gnu/security` which is not
right.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It might be stable one day, but while the functionality of libmalcontent
is growing, the command line tooling will continue to change.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
These tests check that the built `pam_malcontent.so` module can be
loaded using `dlopen()` and that it exports the right symbol. This
should mean that PAM can load it and use it.
Unfortunately, we can’t actually run the module, since PAM hard-codes
its configuration path as being in `/etc`, and there seems to be no way
to override that to load a dummy configuration from a test directory. So
the only way to test the PAM module is to use a file system bind mount
to fake `/etc` (which requires privileges); or to actually install it on
your system and integrate it into your real PAM configuration. Neither
of those are acceptable for a unit test.
It might be possible to re-execute a test under `bwrap` (if installed)
to achieve this, bind mounting a dummy `/etc/pam.d/dummy` service file
into the subprocess’ mount namespace, and otherwise bind mounting `/` to
`/`. It would need a mock malcontent D-Bus API to talk to. Something to
experiment with another time.
(See `_pam_init_handlers()` in
https://github.com/linux-pam/linux-pam/blob/master/libpam/pam_handlers.c
for details of how PAM modules are loaded.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The default value for the `user` argument wasn’t looked up, since
parsing an empty command line doesn’t go through the
`parser_get_app_filter` subparser.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This adds tests for the getter and setter for session limits, giving us
65.9% branch coverage (but that includes `g_return_if_fail()` and
friends, which are impossible and pointless to test both sides of the
branch).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is another extension interface on accountsservice which stores
information about time and usage limits on the user session. Currently,
only a ‘daily schedule’ limit (or no limit) is supported, but additional
types and combinations of limits can be supported in future.
The daily schedule limit allows using the computer between a certain
start time and end time each day (the same each day). The user will be
kicked out of their session when the end time is reached, if they
haven’t already logged out.
This includes the getters for the new data, polkit rules for accessing
it, and some documentation. Changes to `malcontent-client` to support
session limits, setters, and unit tests will all follow.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add a couple of missing exit statuses (and document them) and convert
Malcontent errors to exit statuses more specifically.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This isn’t an API break, as compatibility defines are in place; and the
error code values are the same, so it shouldn’t be an ABI break. The
string value of the error quark has changed, but nobody should be
comparing that against a value which hasn’t come out of libmalcontent,
so changing it should be OK.
This is along the same lines as the previous commit: we don’t need one
error domain per property of an `MctManager`, so reduce the potential
for future duplication by renaming it now.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
If we have a flag type for getting and for setting every type of value
which can be stored on an `MctManager`, that will lead to a load of flag
types which all look identical.
Refactor the types so we only have one shared flags type for getters,
and one for setters.
Add compatibility defines so that this doesn’t break API. It’s not an
ABI break because the flag member values don’t change.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Previously these flags were using automatically assigned enum values,
which would have eventually resulted in having more than one bit set per
flag. Fix that before it happens by explicitly assigning flag-like
values. This was an oversight when they were first written.
This introduces no functional changes because both enums only had one
element so far.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Since it operates only on the app filter. This updates the documentation
too. No compatibility fallback is provided.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Since it operates only on the app filter. This doesn’t update the
documentation because none has been written for this command yet.
No compatibility fallback is provided.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Instead of using non-portable features of GNU ln command, such as -T
and --relative, use Python os.path.relpath function to handle it. This
fixes installation failure on FreeBSD.
Note that this change breaks backward compatibility when handling
content types if the passed argument also resolves to a valid path,
in which case an exception will be raised.
Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com>
Note that this change breaks backward compatibility when handling
flatpak refs/IDs if the passed argument also resolves to a valid path,
in which case an exception will be raised.
Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com>
The cmdline arguments may refer to both paths or flatpak refs so lets
disambiguate here for clarity.
Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com>
This is useful for example if blacklisting all apps that can
handle certain content types is desired.
Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com>
The filter blacklist also holds information on flatpak refs that are
blacklisted (apart from paths), so lets rename it for clarity.
Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com>
Bump our GLib dependency to 2.60 so we can use `gdbus-codegen
--interface-info-{body,header}` to generate interface definitions
dynamically rather than hand-coding them.
We actually need to depend on 2.60.1 so we get
https://gitlab.gnome.org/GNOME/glib/merge_requests/721.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Philip Withnall
Philip Withnall
Ting-Wei Lan
Umang Jain
Andre Moreira Magalhaes