1
0
mirror of https://github.com/systemd/systemd.git synced 2024-12-23 21:35:11 +03:00
Commit Graph

6 Commits

Author SHA1 Message Date
David Tardon
b3579feb59 man: fix indentation 2023-12-26 08:59:53 +01:00
David Tardon
0f095802ad man: add required <title> 2023-12-25 17:59:50 +01:00
David Tardon
bbd0645a3e man: match doctype and root element 2023-12-24 09:23:53 +01:00
Luca Boccassi
6ef721cbc7 user units: implicitly enable PrivateUsers= when sandboxing options are set
Enabling these options when not running as root requires a user
namespace, so implicitly enable PrivateUsers=.
This has a side effect as it changes which users are visible to the unit.
However until now these options did not work at all for user units, and
in practice just a handful of user units in Fedora, Debian and Ubuntu
mistakenly used them (and they have been all fixed since).

This fixes the long-standing confusing issue that the user and system
units take the same options but the behaviour is wildly (and sometimes
silently) different depending on which is which, with user units
requiring manually specifiying PrivateUsers= in order for sandboxing
options to actually work and not be silently ignored.
2023-04-13 21:33:48 +01:00
Ansgar Burchardt
34aee208b5 man/system-or-user-ns.xml: explicitly refer to PrivateUsers= option
It is not clear what "unprivileged user namespaces are available" means.
It could mean either that they are only usable, that is, enabled in the kernel,
or they have been enabled for the specific service. Referring to the
`PrivateUsers=` options makes it clear that the latter is meant.
2022-07-18 13:54:51 +01:00
Luca Boccassi
1219bd4306 Add tests and documentation for all remaining sandboxing in user manager 2022-03-18 10:09:56 +01:00