Let's make missing write access to /proc/sys non-fatal to the sysctl service.
This is a follow-up to 411e869f49 which altered
the condition for running the sysctl service to check for /proc/sys/net being
writable, accepting that /proc/sys might be read-only. In order to ensure the
boot-up stays clean in containers lower the log level for the EROFS errors
generated due to this.
So far "no_gc" was set on -.slice and init.scope, to units that are always
running, cannot be stopped and never exist in an "inactive" state. Since these
units are the only users of this flag, let's remodel it and rename it
"perpetual" and let's derive more funcitonality off it. Specifically, refuse
enqueing stop jobs for these units, and report that they are "unstoppable" in
the CanStop bus property.
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.
Seccomp is generally an unprivileged operation, changing security contexts is
most likely associated with some form of policy. Moreover, while seccomp may
influence our own flow of code quite a bit (much more than the security context
change) make sure to apply the seccomp filters immediately before executing the
binary to invoke.
This also moves enforcement of NNP after the security context change, so that
NNP cannot affect it anymore. (However, the security policy now has to permit
the NNP change).
This change has a good chance of breaking current SELinux/AA/SMACK setups, because
the policy might not expect this change of behaviour. However, it's technically
the better choice I think and should hence be applied.
Fixes: #3993
@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
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.
Switch drivers uses phys_port_name attribute to pass front panel port
name to user. Use it to generate netdev names.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
We would close all the stored fds in service_release_resources(), which of
course broke the whole concept of storing fds over service restart.
Fixes#4408.
I'm seeing strange decompression errors with lz4, which
might be content-dependent. Extend test-compression to allow
testing specific content.
(Edit: PEBKAC: lzcat and lz4cat are not the same beast.
Nevertheless, the test might still be useful in the future.)
This makes applying groups after applying the working directory, this
may allow some flexibility but at same it is not a big deal since we
don't execute or do anything between applying working directory and
droping groups.
Lennart Poettering
Djalal Harouni
Jiří Pírko
Evgeny Vereshchagin
Zbigniew Jędrzejewski-Szmek
Brian J. Murrell
Jakub Wilk
George Hilliard
Lucas Werkmeister
Daniel Mack
Martin Pitt
Michal Sekletar
Thomas H. P. Andersen