| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move over to using GvdbPath when checking for writability of a key.
This has two advantages:
The first is that we only hash the key once during writability checks,
even if we have multiple stacked databases.
The second is that we can now lock down entire subpaths in dconf.
The way the code is written also means that it is now theoretically
possible to "unlock" a given path or key, which means that a database
can introduce a lock for "/" but unlock "/org/gnome/myapp/", in effect,
preventing writes to any area outside of that path. The "best" (ie:
most specific) result is taken as authorative. These 'negative locks'
are not (yet?) supported in the dconf(1) update/compile commands, but
they will be used for proxied databases for application confinement.
Note: each database is consulted separately. That means that a
higher-level database cannot undo a lock of a lower-level database with
a more-specific unlock. The security model is therefore the same as
what it was before.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the case that the user database file does not exist on disk,
"re"opening it for the first time will fail, causing the refresh
function to return FALSE. This means that we will not end up
recomputing the value of has_locks as was previously assumed.
To avoid this problem, we fill in the proper value from the start,
instead of guessing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modify GvdbPath to never allocate memory.
Previously, if we had fewer split points ('/') than the number of
pre-allocated items in the arrays in the structure, we would simply use
them. At 16, this number is already extremely high, and it's
implausible to imagine a real case for which this would be insufficient.
This commit simplifies things a bit: if there are more than 16 segments,
we will just ignore the later ones, except for the final one (ie: the
complete path).
For the sake of an example, let the limit be 4, rather than 16. This
means that you could lock:
/
/org/
/org/gnome/
/org/gnome/app/deeply/nested/key
but not:
/org/gnome/app/
/org/gnome/app/deeply/
/org/gnome/app/deeply/nested/
With 16 segments, everything here could be locked, and much more.
In this way, we preserve the previous behaviour of always being able to
lock a particular individual key of any depth, while introducing
path-based locks for all reasonable cases, and we avoid memory
allocations in all cases.
|
|
|
|
|
|
| |
Write a helper function to answer the question of "does this source have
any lock for the given key?". Although this logic is currently trivial,
it will soon get more complex.
|
|
|
|
|
|
|
|
|
| |
Add a fast path for avoiding writability checks for the very common case
where there are no databases installed that have locks (ie: the default
configuration).
This allows us to avoid iterating a changeset to check for writability
before sending it off to the service, for example.
|
|
|
|
|
| |
Internally refactor GvdbTable lookups to use the GvdbPath API. Add some
external API for doing path lookups.
|
| |
|
|
|
|
| |
... and similar changes to the README.
|
| |
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=759128
|
|
|
|
|
|
|
| |
This was always the intention, and is even documented that way in the
gtk-doc block above. I'm not sure why I used paths.
In any case, this API has never been released, so the change is safe.
|
| |
|
|
|
|
| |
...and other various cleanups.
|
|
|
|
|
|
|
|
|
| |
This API has never appeared in a released version of dconf (even
unstable). Replace it with a more generally-useful form.
Update the test cases, dconf commandline tool and vapi accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=759128
|
|
|
|
|
|
|
| |
There is no reason that the read_through queue should not be 'const', so
expose it as such.
https://bugzilla.gnome.org/show_bug.cgi?id=759128
|
|
|
|
|
|
|
|
| |
Add a flag that allows checking the default value without constructing a
read_through queue. Make use of this new flag to simplify code in a
couple of places.
https://bugzilla.gnome.org/show_bug.cgi?id=759128
|
|
|
|
|
|
|
| |
Delete the separate dconf_engine_read_user_value() and merge its
functionality into dconf_engine_read() by adding a flags field.
https://bugzilla.gnome.org/show_bug.cgi?id=759128
|
|
|
|
|
|
| |
This will soon contain an extra enum.
https://bugzilla.gnome.org/show_bug.cgi?id=759128
|
|
|
|
|
|
|
|
| |
Stop building the dconf-dbus-1 client library. Nobody is using it
anymore and we will soon be taking a non-conditional dependency on
libgio in any case.
It is now only possible to use dconf with GDBus.
|
|
|
|
|
|
|
| |
Add support for g_autoptr() on DConfClient and DConfChangeset. Switch
to using G_DECLARE_FINAL_TYPE in the declaration of DConfClient.
https://bugzilla.gnome.org/show_bug.cgi?id=758871
|
|
|
|
|
| |
We should have this included since we use the functions in it in our
precondition checks.
|
|
|
|
|
|
| |
Add a -d option to 'dconf read' to read the default value.
https://bugzilla.gnome.org/show_bug.cgi?id=758864
|
|
|
|
|
|
|
| |
Add a list-locks command to the dconf commandline tool to list the locks
that are present in the current configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=758864
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=758864
|
|
|
|
|
|
|
| |
Add an API to dconf-engine (and exposed via DConfClient) for getting a
list of locks that are present in a given dconf profile.
https://bugzilla.gnome.org/show_bug.cgi?id=758864
|
|
|
|
|
|
|
|
| |
Add an API to read the default value of a key.
Add a testcase.
https://bugzilla.gnome.org/show_bug.cgi?id=758860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a dir is reset against a DConfChangeset then the result ought to be
that all keys under that dir read as NULL (until such a time as they are
set to a new value).
This is consistent with the (existing) behaviour that a key will read as
NULL if it, itself, was reset.
In order to make that efficient, we create a separate GHashTable to
serve as a cache of all of the directories that have been reset and
iterate it whenever we do a key lookup that doesn't have a direct hit.
We update (and expand) the test case to reflect this new reality -- the
tests actually had a case that relied on the inconsistent behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=744678
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support to dconf-engine for opening "runtime" profiles.
These profiles are intended to be symbolic links or plain files that
will live either in XDG_RUNTIME_DIR/dconf/profile or
/run/dconf/user/$(uid).
This is intended to allow for a PAM module that makes complex decisions
about application of a specific policy to a user and sets up the profile
at login time, thus preventing the need for this complex decision to be
a part of every program that uses dconf. This PAM module would not be
part of dconf, but would rather be a part of a dconf-aware system
administrator framework.
In the case that the profile file is found in /run/dconf, then it will
not be possible for the user to override the profile selection,
including via the DCONF_PROFILE environment variable. This provides a
mechanism for lockdown that is slightly more difficult for a user to
circumvent. In theory, this is pointless since it can still be defeated
with LD_PRELOAD, but in practice this raises the bar quite a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=751417
|
|
|
|
|
| |
This makes coverity happy. It noticed that we check source for
being non-NULL every other case but not here.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=745500
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=744982
|
| |
|
| |
|
| |
|
|
|
|
|
| |
...to better match conventions in other modules, and to silence an
irrelevant warning about portability to Windows.
|
|
|
|
|
| |
...and add a <description> (as mandated by the push hook on
git.gnome.org).
|
| |
|
|
|
|
| |
Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Stock images are deprecated. Dconf-editor uses the GtkImage:stock
property in the close button in the search box. Replace it with the
GtkImage:icon-name property instead.
https://bugzilla.gnome.org/show_bug.cgi?id=739422
|