| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | user units: implicitly enable PrivateUsers= when sandboxing options are set | Luca Boccassi | 2023-04-13 | 1 | -2/+6 |
| | | | | | | | | | | | | | | | | 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. | ||||
| * | man/system-or-user-ns.xml: explicitly refer to `PrivateUsers=` option | Ansgar Burchardt | 2022-07-18 | 1 | -2/+2 |
| | | | | | | | | 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. | ||||
| * | Add tests and documentation for all remaining sandboxing in user manager | Luca Boccassi | 2022-03-18 | 1 | -0/+16 |
 |
index : delta/systemd.git | |
| github.com: systemd/systemd.git |
| summaryrefslogtreecommitdiff |