In service file, if the file has some of special SMACK label in
ExecStart= and systemd has no permission for the special SMACK label
then permission error will occurred. To resolve this, systemd should
be able to set its SMACK label to something accessible of ExecStart=.
So introduce new SmackProcessLabel. If label is specified with
SmackProcessLabel= then the child systemd will set its label to
that. To successfully execute the ExecStart=, accessible label should
be specified with SmackProcessLabel=.
Additionally, by SMACK policy, if the file in ExecStart= has no
SMACK64EXEC then the executed process will have given label by
SmackProcessLabel=. But if the file has SMACK64EXEC then the
SMACK64EXEC label will be overridden.
[zj: reword man page]
systemd-run would fail when run with -M or -H and an absolute path,
if this path did not exists locally. Allow it to continue, since we
don't have a nice way of checking if the binary exists remotely.
The case where -M or -H is used and a local path is unchanged, and we
still iterate over $PATH to find the binary. We need to convert to an
absolute path, and we don't have a nice mechanism to check remotely,
so we assume that the binary will be located in the same place locally
and remotely.
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025418.html
Mips has getrandom() too, but there's just too many variants
for me too care. Either someone who cares does it, or they get
compile-time warnings with old kernel headers.
kdbus has seen a larger update than expected lately, most notably with
kdbusfs, a file system to expose the kdbus control files:
* Each time a file system of this type is mounted, a new kdbus
domain is created.
* The layout inside each mount point is the same as before, except
that domains are not hierarchically nested anymore.
* Domains are therefore also unnamed now.
* Unmounting a kdbusfs will automatically also detroy the
associated domain.
* Hence, the action of creating a kdbus domain is now as
privileged as mounting a filesystem.
* This way, we can get around creating dev nodes for everything,
which is last but not least something that is not limited by
20-bit minor numbers.
The kdbus specific bits in nspawn have all been dropped now, as nspawn
can rely on the container OS to set up its own kdbus domain, simply by
mounting a new instance.
A new set of mounts has been added to mount things *after* the kernel
modules have been loaded. For now, only kdbus is in this set, which is
invoked with mount_setup_late().
The SELinux policy defines no context for some files. E.g.:
$ matchpathcon /run/lock/subsys /dev/mqueue
/run/lock/subsys <<none>>
/dev/mqueue <<none>>
We still need to be able to create them.
In this case selabel_lookup_raw() returns ENOENT. We should then skip
setfscreatecon(), but still return success.
It was broken since c34255bdb2 ("label: unify code to make directories,
symlinks").
Not all switch roots are like base_filesystem_create() wants them
to look like. They might even boot, if they are RO and don't have the FS
layout. Just ignore the error and switch_root nevertheless.
base_filesystem_create() should have logged, what went wrong.
For priviliged units this resource control property ensures that the
processes have all controllers systemd manages enabled.
For unpriviliged services (those with User= set) this ensures that
access rights to the service cgroup is granted to the user in question,
to create further subgroups. Note that this only applies to the
name=systemd hierarchy though, as access to other controllers is not
safe for unpriviliged processes.
Delegate=yes should be set for container scopes where a systemd instance
inside the container shall manage the hierarchies below its own cgroup
and have access to all controllers.
Delegate=yes should also be set for user@.service, so that systemd
--user can run, controlling its own cgroup tree.
This commit changes machined, systemd-nspawn@.service and user@.service
to set this boolean, in order to ensure that container management will
just work, and the user systemd instance can run fine.
The barrier implementation tracks remote states internally. There is no
need to check the return value of any barrier_*() function if the caller
is not interested in the result. The barrier helpers only return the state
of the remote side, which is usually not interesting as later calls to
barrier_sync() will catch this, anyway.
Shut up coverity by explicitly ignoring return values of barrier_place()
if we're not interested in it.
Imagine a constructor like this:
int object_new(void **out) {
void *my_object;
int r;
...
r = ioctl(...);
if (r < 0)
return -errno;
...
*out = my_object;
return 0;
}
We have a lot of those in systemd. If you now call those, gcc might inline
the call and optimize it. However, gcc cannot know that "errno" is
negative if "r" is. Therefore, a caller like this will produce warnings:
r = object_new(&obj);
if (r < 0)
return r;
obj->xyz = "foobar";
In case the ioctl in the constructor fails, gcc might assume "errno" is 0
and thus the error-handling is not triggered. Therefore, "obj" is
uninitialized, but accessed. Gcc will warn about that.
The new negative_errno() helper can be used to mitigate those warnings.
The helper is guaranteed to return a negative integer. Furthermore, it
spills out runtime warnings if "errno" is non-negative.
Instead of returning "-errno", you can use:
return negative_errno();
gcc will no longer assume that this can return >=0, thus, it will not warn
about it.
Use this new helper in libsystemd-terminal to fix some grdev-drm warnings.
