Some registries require getting a token even to download an image
anonymously. So, if no auth has been configured, before prompting
the user for username/password, try without a BasicAuth header.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
If it's an opaque integer on the host system, it might as well be an
opaque integer in the container too.
Fixes: #3416
Signed-off-by: Simon McVittie <smcv@collabora.com>
We can't use the built-in bsearch from the codegen because its an array
instead of a dict, so we have to keep that but its now not using
variant at least.
These are subsets of the host keyword, which provide access to operating
system files but not to users' personal files.
In particular, the experimental support for namespace-based sandboxes
in the Steam Runtime[1] uses the graphics stack from the host system,
which requires access to the host /usr/libQUAL, /libQUAL (even if the
host OS has undergone the /usr merge, the canonical paths of ELF
interpreters start with /lib), /etc/ld.so.cache, and for some libraries
on Debian-based systems, /etc/alternatives. It will not be possible to
do similar things in Flatpak without either allowing full host
filesystem access (which exposes personal files, and in any case cannot
be done by the Steam app because it is incompatible with --persist=.),
or adding the ability to expose /usr and related directories without
including the rest of the host filesystem.
To the best of my knowledge, host-etc is not necessary for anything;
I've mainly provided it for symmetry, since it's the other significant
thing that we mount in /run/host and cannot get via --filesystem=/path.
Some notes on the security/privacy implications of the new keywords:
- Neither new keyword allows anything that was not already allowed
by "host".
- Neither new keyword can allow anything that was not already allowed
to the user outside the sandbox.
- "host-os" allows enumeration of the installed packages on the host
system, and often their version numbers too. A malicious app could
use this to look for exploitable security vulnerabilities on the
host system. An app could also use this for fingerprinting, although
this is not a regression, because the systemd/D-Bus machine ID,
MAC addresses, hostname, kernel boot UUID, DMI product ID and many
other unique or relatively unique properties are already available
inside the sandbox.
- "host-os" allows read access, and possibly write access (if the user
has it outside the sandbox, for example members of group 'staff' in
older Debian installations), to /usr/local.
- "host-etc" allows reading configuration files whose contents might
be considered sensitive, such as /etc/passwd.
[1] https://steamcommunity.com/app/221410/discussions/0/1638675549018366706/
Signed-off-by: Simon McVittie <smcv@collabora.com>
Currently there are only "home" and "host", but I'm going to add one
that represents /usr and friends (/usr, /lib, ...), and one for /etc.
These differ from ordinary filesystem mounts because they are redirected
into /run/host to avoid conflicting with the runtime.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In a host system where the /usr merge has not been implemented, these can
be necessary to load or inspect libraries or executables from the host
system. They are conceptually the same as /usr.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In some places we want a list of basenames, and in others we want a list
of absolute paths. Use the absolute paths, because converting those into
basenames doesn't require memory allocation.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This syncs it up with our other lists of /usr-merged directories.
In particular, this could matter on Arch Linux, which uses /usr/lib
and /usr/lib32 for 64- and 32-bit libraries (respectively), instead
of the more common /usr/lib64 and /usr/lib.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We can choose this once and use it repeatedly, which will be simpler
when we add more directories that work this way.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This breaks Deploy which can't find the ref. It used to work due to
the extra non-mirroring pull in flatpak_dir_setup_extra_data, but
this is not needed here.
As noticed in https://github.com/flatpak/flatpak/issues/3412 we
regressed at some point and are no longer using from-scratch deltas.
This is caused by an optimization in ostree where it decides to not
use a from-scratch deltas if theres is *some* version of the ref
locally available.
This conflicts with some code in flatpak that pulls *only* the commit
object in order to look for extra data size information so that we can
get the progress reporting right. Unfortunately the existance of
just the object triggers the above causing us to *never* use from-scratch
deltas.
We fix this by throwing away the partial pull in an aborted ostree
transaction.
It is a common user error to prepend many flatpak commands with sudo
and doing so with run is quite unsafe and can cause issues.
This check simply handles the `sudo flatpak run foo` case and does
not prevent running as root or even running in a shell created by
sudo.
See also #1357
We don't need to check for GLib 2.44 (the first release with g_autoptr()
support) since Flatpak requires that version in configure.ac.
Fixes https://github.com/flatpak/flatpak/issues/3403
In flatpak_dir_create_origin_remote() we reload the repo config after
adding an origin remote to it, but this only applies to the FlatpakDir
object used. In the case of flatpak_transaction_add_ref(), there is
another FlatpakDir object in the installation (priv->installation) which
needs to also be reloaded using flatpak_installation_drop_caches(). So
add a boolean out variable to flatpak_dir_create_origin_remote() and use
it to determine if it's necessary to call
flatpak_installation_drop_caches() (because if the origin remote already
exists we don't create another).
This commit also makes related changes at the other call sites of
create_origin_remote() (some indirectly via
flatpak_dir_ensure_bundle_remote()):
- in flatpak_dir_ensure_bundle_remote(), only set the out variable
created_remote to TRUE if a new remote was actually created
- in flatpak_installation_install_bundle(), only drop the installation
caches if a new remote was actually created
- in flatpak_transaction_resolve_bundles(), drop a redundant
flatpak_dir_recreate_repo() call and only drop installation caches
when necessary
Without these changes, this unit test failure occurs:
ERROR: testlibrary - Bail out!
flatpak:ERROR:tests/testlibrary.c:3311:test_transaction_install_local:
assertion failed (error == NULL): Remote "hello-origin" not found
(flatpak-error-quark, 7)
In test_transaction_install_local(), we test that the origin remote
created when installing from a local repo doesn't exist before
flatpak_transaction_run() is executed and does exist afterward. However,
the origin remote is created before the transaction is run; see the
flatpak_dir_create_origin_remote() call in
flatpak_transaction_add_ref(). The only reason this discrepancy has not
caused a test failure is that the FlatpakDir object held by the
FlatpakInstallation object is not reloaded when the origin remote is
added (so it's reading an old copy of the repo config). This issue will
be fixed in the commit following this one.
