summaryrefslogtreecommitdiff
path: root/man/systemd.exec.xml
AgeCommit message (Collapse)Author
2017-02-03core/execute: set HOME, USER also for root usersZbigniew Jędrzejewski-Szmek
This changes the environment for services running as root from: LANG=C.utf8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin INVOCATION_ID=ffbdec203c69499a9b83199333e31555 JOURNAL_STREAM=8:1614518 to LANG=C.utf8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin HOME=/root LOGNAME=root USER=root SHELL=/bin/sh INVOCATION_ID=15a077963d7b4ca0b82c91dc6519f87c JOURNAL_STREAM=8:1616718 Making the environment special for the root user complicates things unnecessarily. This change simplifies both our logic (by making the setting of the variables unconditional), and should also simplify the logic in services (particularly scripts). Fixes #5124.
2017-02-02man: fix spelling error parth -> pathBrandon Philips
2017-01-19man: fix typos (#5109)Jakub Wilk
2017-01-17Merge pull request #4991 from poettering/seccomp-fixZbigniew Jędrzejewski-Szmek
2017-01-11Merge pull request #5009 from ian-kelling/ian-mnt-namespace-docZbigniew Jędrzejewski-Szmek
2017-01-03doc: MountFlags= don't reference container which may not exist (#5011)Ian Kelling
2017-01-03doc: correct "or" to "and" in MountFlags= description (#5010)Ian Kelling
2017-01-03man: document mount deletion between commandsIan Kelling
2016-12-29Merge pull request #4994 from poettering/private-tmp-tmpfilesMartin Pitt
automatically clean up PrivateTmp= left-overs in /var/tmp on next boot
2016-12-29man: add brief documentation for the (sd-pam) processes created due to ↵Lennart Poettering
PAMName= (#4967) A follow-up for #4942, adding a brief but more correct explanation of the processes.
2016-12-27core: implicitly order units with PrivateTmp= after ↵Lennart Poettering
systemd-tmpfiles-setup.service Preparation for fixing #4401.
2016-12-27seccomp: add two new filter sets: @reboot and @swapLennart Poettering
These groupe reboot()/kexec() and swapon()/swapoff() respectively
2016-12-14core: add ability to define arbitrary bind mounts for servicesLennart Poettering
This adds two new settings BindPaths= and BindReadOnlyPaths=. They allow defining arbitrary bind mounts specific to particular services. This is particularly useful for services with RootDirectory= set as this permits making specific bits of the host directory available to chrooted services. The two new settings follow the concepts nspawn already possess in --bind= and --bind-ro=, as well as the .nspawn settings Bind= and BindReadOnly= (and these latter options should probably be renamed to BindPaths= and BindReadOnlyPaths= too). Fixes: #3439
2016-12-06man: fix $SERVICE_RESULT/$EXIT_CODE/$EXIT_STATUS documentationJouke Witteveen
Note that any exit code is available through $EXIT_STATUS and not through $EXIT_CODE. This mimics siginfo.
2016-11-29bus-util: add protocol error type explanationJouke Witteveen
2016-11-23man: document protocol error type for service failures (#4724)Jouke Witteveen
2016-11-21seccomp: add @filesystem syscall group (#4537)Lennart Poettering
@filesystem groups various file system operations, such as opening files and directories for read/write and stat()ing them, plus renaming, deleting, symlinking, hardlinking.
2016-11-17namespace: simplify, optimize and extend handling of mounts for namespaceLennart Poettering
This changes a couple of things in the namespace handling: It merges the BindMount and TargetMount structures. They are mostly the same, hence let's just use the same structue, and rely on C's implicit zero initialization of partially initialized structures for the unneeded fields. This reworks memory management of each entry a bit. It now contains one "const" and one "malloc" path. We use the former whenever we can, but use the latter when we have to, which is the case when we have to chase symlinks or prefix a root directory. This means in the common case we don't actually need to allocate any dynamic memory. To make this easy to use we add an accessor function bind_mount_path() which retrieves the right path string from a BindMount structure. While we are at it, also permit "+" as prefix for dirs configured with ReadOnlyPaths= and friends: if specified the root directory of the unit is implicited prefixed. This also drops set_bind_mount() and uses C99 structure initialization instead, which I think is more readable and clarifies what is being done. This drops append_protect_kernel_tunables() and append_protect_kernel_modules() as append_static_mounts() is now simple enough to be called directly. Prefixing with the root dir is now done in an explicit step in prefix_where_needed(). It will prepend the root directory on each entry that doesn't have it prefixed yet. The latter is determined depending on an extra bit in the BindMount structure.
2016-11-15doc: move ProtectKernelModules= documentation near ProtectKernelTunalbes=Djalal Harouni
2016-11-15doc: note when no new privileges is impliedDjalal Harouni
2016-11-04core: add new RestrictNamespaces= unit file settingLennart Poettering
This new setting permits restricting whether namespaces may be created and managed by processes started by a unit. It installs a seccomp filter blocking certain invocations of unshare(), clone() and setns(). RestrictNamespaces=no is the default, and does not restrict namespaces in any way. RestrictNamespaces=yes takes away the ability to create or manage any kind of namspace. "RestrictNamespaces=mnt ipc" restricts the creation of namespaces so that only mount and IPC namespaces may be created/managed, but no other kind of namespaces. This setting should be improve security quite a bit as in particular user namespacing was a major source of CVEs in the kernel in the past, and is accessible to unprivileged processes. With this setting the entire attack surface may be removed for system services that do not make use of namespaces.
2016-11-03Merge pull request #4548 from keszybz/seccomp-helpZbigniew Jędrzejewski-Szmek
systemd-analyze syscall-filter
2016-11-03doc: clarify NoNewPrivileges (#4562)Kees Cook
Setting no_new_privs does not stop UID changes, but rather blocks gaining privileges through execve(). Also fixes a small typo.
2016-11-03seccomp-util, analyze: export comments as a help stringZbigniew Jędrzejewski-Szmek
Just to make the whole thing easier for users.
2016-11-03analyze: add syscall-filter verbZbigniew Jędrzejewski-Szmek
This should make it easier for users to understand what each filter means as the list of syscalls is updated in subsequent systemd versions.
2016-11-02man: document that too strict system call filters may affect the service managerLennart Poettering
If execve() or socket() is filtered the service manager might get into trouble executing the service binary, or handling any failures when this fails. Mention this in the documentation. The other option would be to implicitly whitelist all system calls that are required for these codepaths. However, that appears less than desirable as this would mean socket() and many related calls have to be whitelisted unconditionally. As writing system call filters requires a certain level of expertise anyway it sounds like the better option to simply document these issues and suggest that the user disables system call filters in the service temporarily in order to debug any such failures. See: #3993.
2016-11-02seccomp: add two new syscall groupsLennart Poettering
@resources contains various syscalls that alter resource limits and memory and scheduling parameters of processes. As such they are good candidates to block for most services. @basic-io contains a number of basic syscalls for I/O, similar to the list seccomp v1 permitted but slightly more complete. It should be useful for building basic whitelisting for minimal sandboxes
2016-11-02man: two minor fixesLennart Poettering
2016-11-02seccomp: include pipes and memfd in @ipcLennart Poettering
These system calls clearly fall in the @ipc category, hence should be listed there, simply to avoid confusion and surprise by the user.
2016-11-02seccomp: drop execve() from @process listLennart Poettering
The system call is already part in @default hence implicitly allowed anyway. Also, if it is actually blocked then systemd couldn't execute the service in question anymore, since the application of seccomp is immediately followed by it.
2016-11-02seccomp: add clock query and sleeping syscalls to "@default" groupLennart Poettering
Timing and sleep are so basic operations, it makes very little sense to ever block them, hence don't.
2016-11-01seccomp: allow specifying arm64, mips, ppc (#4491)Zbigniew Jędrzejewski-Szmek
"Secondary arch" table for mips is entirely speculative…
2016-10-31man: fix typos (#4527)Jakub Wilk
2016-10-28Merge pull request #4495 from topimiettinen/block-shmat-execDjalal Harouni
seccomp: also block shmat(..., SHM_EXEC) for MemoryDenyWriteExecute
2016-10-26seccomp: also block shmat(..., SHM_EXEC) for MemoryDenyWriteExecuteTopi Miettinen
shmat(..., SHM_EXEC) can be used to create writable and executable memory, so let's block it when MemoryDenyWriteExecute is set.
2016-10-24man: document the default value of NoNewPrivileges=Zbigniew Jędrzejewski-Szmek
Fixes #4329.
2016-10-20man: document default for User=Lennart Poettering
Replaces: #4375
2016-10-17core/exec: add a named-descriptor option ("fd") for streams (#4179)Luca Bruno
This commit adds a `fd` option to `StandardInput=`, `StandardOutput=` and `StandardError=` properties in order to connect standard streams to externally named descriptors provided by some socket units. This option looks for a file descriptor named as the corresponding stream. Custom names can be specified, separated by a colon. If multiple name-matches exist, the first matching fd will be used.
2016-10-17man: avoid abbreviated "cgroups" terminology (#4396)Lennart Poettering
Let's avoid the overly abbreviated "cgroups" terminology. Let's instead write: "Linux Control Groups (cgroups)" is the long form wherever the term is introduced in prose. Use "control groups" in the short form wherever the term is used within brief explanations. Follow-up to: #4381
2016-10-15man: add crosslink between systemd.resource-control(5) and systemd.exec(5)Zbigniew Jędrzejewski-Szmek
Fixes #4379.
2016-10-13Merge pull request #4243 from ↵Lennart Poettering
endocode/djalal/sandbox-first-protection-kernelmodules-v1 core:sandbox: Add ProtectKernelModules= and some fixes
2016-10-12man: typo fixesThomas Hindoe Paaboel Andersen
A mix of fixes for typos and UK english
2016-10-12core:sandbox: lets make /lib/modules/ inaccessible on ProtectKernelModules=Djalal Harouni
Lets go further and make /lib/modules/ inaccessible for services that do not have business with modules, this is a minor improvment but it may help on setups with custom modules and they are limited... in regard of kernel auto-load feature. This change introduce NameSpaceInfo struct which we may embed later inside ExecContext but for now lets just reduce the argument number to setup_namespace() and merge ProtectKernelModules feature.
2016-10-12doc: minor hint about InaccessiblePaths= in regard of ProtectKernelTunables=Djalal Harouni
2016-10-12core:sandbox: remove CAP_SYS_RAWIO on PrivateDevices=yesDjalal Harouni
The rawio system calls were filtered, but CAP_SYS_RAWIO allows to access raw data through /proc, ioctl and some other exotic system calls...
2016-10-12core:sandbox: Add ProtectKernelModules= optionDjalal Harouni
This is useful to turn off explicit module load and unload operations on modular kernels. This option removes CAP_SYS_MODULE from the capability bounding set for the unit, and installs a system call filter to block module system calls. This option will not prevent the kernel from loading modules using the module auto-load feature which is a system wide operation.
2016-10-11Merge pull request #4348 from poettering/docfixesZbigniew Jędrzejewski-Szmek
Various smaller documentation fixes.
2016-10-11man: beef up documentation on per-unit resource limits a bitLennart Poettering
Let's clarify that for user services some OS-defined limits bound the settings in the unit files. Fixes: #4232
2016-10-07core: add "invocation ID" concept to service managerLennart Poettering
This adds a new invocation ID concept to the service manager. The invocation ID identifies each runtime cycle of a unit uniquely. A new randomized 128bit ID is generated each time a unit moves from and inactive to an activating or active state. The primary usecase for this concept is to connect the runtime data PID 1 maintains about a service with the offline data the journal stores about it. Previously we'd use the unit name plus start/stop times, which however is highly racy since the journal will generally process log data after the service already ended. The "invocation ID" kinda matches the "boot ID" concept of the Linux kernel, except that it applies to an individual unit instead of the whole system. The invocation ID is passed to the activated processes as environment variable. It is additionally stored as extended attribute on the cgroup of the unit. The latter is used by journald to automatically retrieve it for each log logged message and attach it to the log entry. The environment variable is very easily accessible, even for unprivileged services. OTOH the extended attribute is only accessible to privileged processes (this is because cgroupfs only supports the "trusted." xattr namespace, not "user."). The environment variable may be altered by services, the extended attribute may not be, hence is the better choice for the journal. Note that reading the invocation ID off the extended attribute from journald is racy, similar to the way reading the unit name for a logging process is. This patch adds APIs to read the invocation ID to sd-id128: sd_id128_get_invocation() may be used in a similar fashion to sd_id128_get_boot(). PID1's own logging is updated to always include the invocation ID when it logs information about a unit. A new bus call GetUnitByInvocationID() is added that allows retrieving a bus path to a unit by its invocation ID. The bus path is built using the invocation ID, thus providing a path for referring to a unit that is valid only for the current runtime cycleof it. Outlook for the future: should the kernel eventually allow passing of cgroup information along AF_UNIX/SOCK_DGRAM messages via a unique cgroup id, then we can alter the invocation ID to be generated as hash from that rather than entirely randomly. This way we can derive the invocation race-freely from the messages.
2016-10-05seccomp: add support for the s390 architecture (#4287)hbrueckner
Add seccomp support for the s390 architecture (31-bit and 64-bit) to systemd. This requires libseccomp >= 2.3.1.