st_size is a 64-bit off_t but was truncated to gsize which is
32-bit on 32-bit platforms. A file larger than G_MAXSIZE - 1 would
cause size + 1 to overflow to 0, leading to a zero-size allocation
followed by an oversized read.
A symlink loop on the host filesystem would cause infinite recursion
and a stack overflow. Limit to 40 levels, matching the kernel's ELOOP
limit and the existing check in _exports_path_expose.
The check tests sandbox_flags but the error message formatted
arg_flags, showing unrelated spawn flags instead of the actual
unsupported sandbox flags.
If a negated true conditional (e.g. `!true`) is evaludated, it should
always be considered false. However, the code would not do that
(continue to the next conditional), but instead falls through to the
evaluator which grants the permission, because
evaluator (condition) == !negated
... and the evaluator evaluates unknown conditions as false.
If we created an instance and we failed to get the PID of the instance,
we would still succeed. If one later calls flatpak_instance_is_running
or uses the result of flatpak_instance_get_pid with kill, it's possible
to terminate the entire process group (kill 0).
Let's just error out as early as possible to avoid those weird
half-initialized cases.
That unfortunately means we have to adjust a bunch of callers as well,
but fortunately, this only affects internal API.
glib-mkenums fails to generate proper nicks and strips away th non- and
no-. Fix those cases manually.
Also fix the header guard while at it.
Technically this is an API break, but the API does exactly the opposite
of what it promises, so if anyone depended on this, we probably would
have received a bug report. Let's take the risk and just change it.
If max_len is 0, either data1_len or data2_len is 0, which means we
would add -1 to either data1 or data2, making them point one byte before
the object which is UB.
This commit just changes match_bytes_at_end and match_bytes_at_start to
use index based comparisons which makes the code easier and less likely
to invoke UB.
_ostree_object_name_equal() derived both refs from parameter a,
so any two objects in the same hash bucket were considered equal.
This caused g_hash_table_add() to evict previously inserted objects
on hash collision, shrinking the reachable set below its true size
and potentially pruning objects that are still in use.
The code checked the wrong flags. struct_props is the array of child
properties, so struct_props->flags is the flags of the first child
property. What we need to chech is the flags of the current property,
and if it contains FLATPAK_JSON_PROP_FLAGS_STRICT.
Copy and paste error which results in the default and explicit usage of
--clear-env to be inverted.
Fixes: f760f1b5 ("run: Add --clear-env option for clearing the outside environment")
It was accidentally parsed into the product union member but because it
has the same layout as the vendor one, this didn't turn into a bug in
practice, but it probably is UB.
As per g_type_ensure's documentation it is technically incorrect to mark
_get_type fns with G_GNUC_CONST since they have side-effects on their
first run.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/5223 for more
details.
This constraints the scope of the variables within instead of
unnecessarily creating global variables, and it makes it easier to keep
only a single sys.exit
coredumpctl is required for both subcommands, and likely will be for any
others added in the future, so we should just check for it in one place
at the start.
Reworks the interface of flatpak-coredumpctl to use subcommands
similar to those of coredumpctl. The new list subcommand is currently
non-functional, but will list all store coredumps from flatpak
applications, and the previous debugger functionality has been moved to
the debug subcommand.
flatpak-coredumpctl: Implement basic functionality for 'list' subcommand
Resolves#2002: 'flatpak-coredumpctl list' now lists coredumps
in a format similar to coredumpctl, except that it skips inaccessible
coredumps by default
flatpak-coredumpctl: Use a pager for list output
These less flags don't perfectly match coredumpctl because it uses
systemd's pager instead of less, but it's close enough
flatpak-coredumpctl: Match coredumpctl's text styling
The column titles are now underlined and missing/inaccessible coredumps
are grayed out.
This is probably just a little overengineered for what is needed, but I
wanted to make it easy to expand in the future if needed, and it is
still fairly minimal.
flatpak-coredumpctl: Add matches argument to list subcommand
Verify that the file object is valid before checking its cached path
to avoid a potential NULL pointer dereference.
Fixes: c4fce9e4 ("run: Error out if file forwarding of empty paths is attempted")
During a system install with the system helper enabled, the initial
network pull goes to a temporary repo and then via pull local from that
repo to the final system repo while during user install there is only
one pull from network to the final repo.
c672c55 set the logger to use the temporary repo path as installation
but the history command afc87ad since the same day filters the initial
pull out as the installation name will never match the temporary path.
This causes the initial pull operation to be never show up in flatpak
history when using system installs while they work for user installs as
`INSTALLATION=user`.
This is presumably also broken for custom installations as they
will similarly not match the temp repo path.
So don't pass the path at all to flatpak_dir_log and we can later
fall back via flatpak_dir_get_name_cached() which sets the correct
`INSTALLATION` for system installs ie. `INSTALLATION=system`.
This also allows us to remove the workaround of adding two different
expected history outputs from ad1ff6d as both branches log the pull.
Without system helper `flatpak install` needs to be executed as
priviledged to operate on system install so the initial pull was
always logged correctly for that branch.
Help messages were inconsistent about whether they ended with periods or
not. I chose to remove the periods from those that had them rather than
the other way around because the help messages automatically generated
by argparse do not have periods.
There are a couple related changes made here, with the intention of
making it easier to implement additional features in the future:
- Mutual exclusivity of --build-directory and app is better enforced
both through types and at runtime. The types will let type checkers
ensure that we cannot reach the run function without at least one of
them being valid. At runtime, it no longer allows both to be
specified, which could result in confusion over which takes
precedence.
- Instead of wrapping the entire program in a class, there is now only a
small class that handles validation of the arguments and holding the
data to be passed to run. This provides a better separation of
concerns, with the argument parsing now being a little less tied to
running the debugger.
Sebastian Wick