1
0
mirror of https://github.com/systemd/systemd synced 2025-11-07 10:54:44 +01:00

Compare commits

..

7 Commits

Author SHA1 Message Date
Anita Zhang
848cfa74d2
Merge pull request #15636 from poettering/sensitivity-training
be more careful when setting json variant + dbus message sensitive flag
2020-05-04 17:48:13 -07:00
Anita Zhang
53491f7fe7
Merge pull request #15647 from benzea/benzea/graphical-use-app-prefix
docs: Change prefix for desktop applications to app-
2020-05-04 16:28:51 -07:00
Michal Koutný
05d9125ece mkosi: Fix openSUSE image declaration
User accounts of given names are necessary for the build script and
tests to succeed.

(Fixup of #15527, too keen cleaning of dependencies and cached image
caused this.)
2020-05-04 22:12:58 +02:00
Benjamin Berg
60ca8f22b8 docs: Change prefix for desktop applications to app-
We need both a slice name and a prefix for application units. For
consistency we tried to use the same name and ended up standardising on
"apps.slice" and and "apps-" prefix for the units.

However, "app-" would be a more natural prefix for applications. And it
is no problem to simply also name the slice "app.slice" for consistency
rather than keeping the current "apps.slice".
2020-04-30 14:21:44 +02:00
Lennart Poettering
560a3e5dd6 home: make sure whenever we touch the 'secret' part of a user record, we set the the sensitive flag on it 2020-04-29 16:32:46 +02:00
Lennart Poettering
2ffee2c9b0 home: mark various bus messages we write user records to as sensitive
let's make sure that when we append potentially sensitive data to a bus
message we set the sensitive flag on the message object.
2020-04-29 16:32:46 +02:00
Lennart Poettering
94600eeb29 json: when making a copy of a json variant, propagate the sensitive bit
Let's make sure we never lose the bit when copying a variant, after all
the data contained is still going to be sensitive after the copy.
2020-04-29 16:32:46 +02:00
7 changed files with 58 additions and 11 deletions

View File

@ -48,11 +48,15 @@ BuildPackages=
python3
python3-lxml
qrencode-devel
system-user-nobody
zlib-devel
# to satisfy tests
acl
glibc-locale
system-group-obsolete
system-user-bin
system-user-daemon
system-user-root
timezone
Packages=

View File

@ -28,11 +28,11 @@ Currently nothing like this is supported or even planned.
[`systemd.special(7)`](https://www.freedesktop.org/software/systemd/man/systemd.special.html)
defines the `graphical-session.target` and `graphical-session-pre.target` to
allow cross-desktop integration. Furthermore, systemd defines the three base
slices `background`, `apps` and `session`.
slices `background`, `app` and `session`.
All units should be placed into one of these slices depending on their purposes:
* `session.slice`: Contains only processes essential to run the user's graphical session
* `apps.slice`: Contains all normal applications that the user is running
* `app.slice`: Contains all normal applications that the user is running
* `background.slice`: Useful for low-priority background tasks
The purpose of this grouping is to assign different priorities to the
@ -42,7 +42,7 @@ preferentially killing background tasks in out-of-memory situations
or assigning different memory/CPU/IO priorities to ensure that the session
runs smoothly under load.
TODO: Will there be a default to place units into e.g. `apps.slice` by default
TODO: Will there be a default to place units into e.g. `app.slice` by default
rather than the root slice?
## XDG standardization for applications
@ -50,9 +50,9 @@ rather than the root slice?
To ensure cross-desktop compatibility and encourage sharing of good practices,
desktop environments should adhere to the following conventions:
* Application units should follow the scheme `apps-<launcher>-<ApplicationID>-<RANDOM>.service`,
e.g. `apps-gnome-org.gnome.Evince-12345.service`,
`apps-flatpak-org.telegram.desktop-12345.service` or `apps-KDE-org.kde.okular-12345.service`.
* Application units should follow the scheme `app-<launcher>-<ApplicationID>-<RANDOM>.service`,
e.g. `app-gnome-org.gnome.Evince-12345.service`,
`app-flatpak-org.telegram.desktop-12345.service` or `app-KDE-org.kde.okular-12345.service`.
* Using `.service` units instead of `.scope` units, i.e. allowing systemd to
start the process on behalf of the caller,
instead of the caller starting the process and letting systemd know about it,
@ -62,13 +62,13 @@ desktop environments should adhere to the following conventions:
contain a `-` character.
This has the following advantages:
* Using the `apps-<launcher>-` prefix means that the unit defaults can be
* Using the `app-<launcher>-` prefix means that the unit defaults can be
adjusted using desktop environment specific drop-in files.
* The application ID can be retrieved by stripping the prefix and postfix.
This in turn should map to the corresponding `.desktop` file when available
TODO: Define the name of slices that should be used.
This could be `apps-<launcher>-<ApplicationID>-<RANDOM>.slice`.
This could be `app-<launcher>-<ApplicationID>-<RANDOM>.slice`.
TODO: Does it really make sense to insert the `<launcher>`? In GNOME I am
currently using a drop-in to configure `BindTo=graphical-session.target`,
@ -78,7 +78,7 @@ global default for all (graphical) applications.
* Should application lifetime be bound to the session?
* May the user have applications that do not belong to the graphical session (e.g. launched from SSH)?
* Could we maybe add a default `apps-.service.d` drop-in configuration?
* Could we maybe add a default `app-.service.d` drop-in configuration?
## XDG autostart integration

View File

@ -124,6 +124,8 @@ int bus_message_append_secret(sd_bus_message *m, UserRecord *secret) {
if (r < 0)
return r;
(void) sd_bus_message_sensitive(m);
return sd_bus_message_append(m, "s", formatted);
}

View File

@ -1435,6 +1435,8 @@ static int create_home(int argc, char *argv[], void *userdata) {
if (r < 0)
return bus_log_create_error(r);
(void) sd_bus_message_sensitive(m);
r = sd_bus_message_append(m, "s", formatted);
if (r < 0)
return bus_log_create_error(r);
@ -1637,6 +1639,8 @@ static int update_home(int argc, char *argv[], void *userdata) {
if (r < 0)
return r;
(void) sd_bus_message_sensitive(m);
r = sd_bus_message_append(m, "s", formatted);
if (r < 0)
return bus_log_create_error(r);

View File

@ -840,6 +840,8 @@ int user_record_set_password(UserRecord *h, char **password, bool prepend) {
if (r < 0)
return r;
json_variant_sensitive(w);
r = json_variant_set_field(&h->json, "secret", w);
if (r < 0)
return r;
@ -900,6 +902,8 @@ int user_record_set_pkcs11_pin(UserRecord *h, char **pin, bool prepend) {
if (r < 0)
return r;
json_variant_sensitive(w);
r = json_variant_set_field(&h->json, "secret", w);
if (r < 0)
return r;
@ -927,8 +931,11 @@ int user_record_set_pkcs11_protected_authentication_path_permitted(UserRecord *h
if (json_variant_is_blank_object(w))
r = json_variant_filter(&h->json, STRV_MAKE("secret"));
else
else {
json_variant_sensitive(w);
r = json_variant_set_field(&h->json, "secret", w);
}
if (r < 0)
return r;

View File

@ -1396,6 +1396,19 @@ void json_variant_sensitive(JsonVariant *v) {
v->sensitive = true;
}
bool json_variant_is_sensitive(JsonVariant *v) {
v = json_variant_formalize(v);
if (!json_variant_is_regular(v))
return false;
return v->sensitive;
}
static void json_variant_propagate_sensitive(JsonVariant *from, JsonVariant *to) {
if (json_variant_is_sensitive(from))
json_variant_sensitive(to);
}
int json_variant_get_source(JsonVariant *v, const char **ret_source, unsigned *ret_line, unsigned *ret_column) {
assert_return(v, -EINVAL);
@ -1829,6 +1842,8 @@ int json_variant_filter(JsonVariant **v, char **to_remove) {
if (r < 0)
return r;
json_variant_propagate_sensitive(*v, w);
json_variant_unref(*v);
*v = TAKE_PTR(w);
@ -1898,6 +1913,8 @@ int json_variant_set_field(JsonVariant **v, const char *field, JsonVariant *valu
if (r < 0)
return r;
json_variant_propagate_sensitive(*v, w);
json_variant_unref(*v);
*v = TAKE_PTR(w);
@ -2005,6 +2022,9 @@ int json_variant_merge(JsonVariant **v, JsonVariant *m) {
if (r < 0)
return r;
json_variant_propagate_sensitive(*v, w);
json_variant_propagate_sensitive(m, w);
json_variant_unref(*v);
*v = TAKE_PTR(w);
@ -2044,10 +2064,11 @@ int json_variant_append_array(JsonVariant **v, JsonVariant *element) {
r = json_variant_new_array(&nv, array, i + 1);
}
if (r < 0)
return r;
json_variant_propagate_sensitive(*v, nv);
json_variant_unref(*v);
*v = TAKE_PTR(nv);
@ -2193,6 +2214,8 @@ static int json_variant_copy(JsonVariant **nv, JsonVariant *v) {
memcpy_safe(&c->value, source, k);
json_variant_propagate_sensitive(v, c);
*nv = c;
return 0;
}
@ -4178,6 +4201,9 @@ int json_variant_sort(JsonVariant **v) {
r = json_variant_new_object(&n, a, m);
if (r < 0)
return r;
json_variant_propagate_sensitive(*v, n);
if (!n->sorted) /* Check if this worked. This will fail if there are multiple identical keys used. */
return -ENOTUNIQ;
@ -4226,6 +4252,9 @@ int json_variant_normalize(JsonVariant **v) {
}
if (r < 0)
goto finish;
json_variant_propagate_sensitive(*v, n);
if (!n->normalized) { /* Let's see if normalization worked. It will fail if there are multiple
* identical keys used in the same object anywhere, or if there are floating
* point numbers used (see below) */

View File

@ -135,6 +135,7 @@ JsonVariant *json_variant_by_key_full(JsonVariant *v, const char *key, JsonVaria
bool json_variant_equal(JsonVariant *a, JsonVariant *b);
void json_variant_sensitive(JsonVariant *v);
bool json_variant_is_sensitive(JsonVariant *v);
struct json_variant_foreach_state {
JsonVariant *variant;