This macro will read a pointer of any type, return it, and set the
pointer to NULL. This is useful as an explicit concept of passing
ownership of a memory area between pointers.
This takes inspiration from Rust:
https://doc.rust-lang.org/std/option/enum.Option.html#method.take
and was suggested by Alan Jenkins (@sourcejedi).
It drops ~160 lines of code from our codebase, which makes me like it.
Also, I think it clarifies passing of ownership, and thus helps
readability a bit (at least for the initiated who know the new macro)
Otherwise we can be fooled if one path component is replaced underneath us.
The patch achieves that by always operating at file descriptor level (by using
*at() helpers) and by making sure we do not any path resolution when traversing
direcotry trees.
However this is not always possible, for instance when listing the content of a
directory or some operations don't provide the *at() helpers or others (such as
fchmodat()) don't have the AT_EMPTY_PATH flag. In such cases we operate on
/proc/self/fd/%i pseudo-symlink instead, which works the same for all kinds of
objects and requires no checking of type beforehand.
Also O_PATH flag is used when opening file objects in order to prevent
undesired behaviors: device nodes from reacting, automounts from
triggering, etc...
Fixes: #7986
Fixes: CVE-2018-6954
CHANGE OF BEHAVIOUR — with this commit "f" line's behaviour is altered
to match what the documentation says: if an "argument" string is
specified it is written to the file only when the file didn't exist
before. Previously, it would be appended to the file each time
systemd-tmpfiles was invoked — which is not a particularly useful
behaviour as the tool is not idempotent then and the indicated files
grow without bounds each time the tool is invoked.
I did some spelunking whether this change in behaviour would break
things, but afaics nothing relies on the previous O_APPEND behaviour of
this line type, hence I think it's relatively safe to make "f" lines
work the way the docs say, rather than adding a new modifier for it or
so.
Triggered by:
https://lists.freedesktop.org/archives/systemd-devel/2018-January/040171.html
Currently, we create leading directories implicitly for all lines that
create directory or directory-like nodes.
With this, we also do the same for a number of other lines: f/F, C, p,
L, c/b (that is regular files, pipes, symlinks, device nodes as well as
file trees we copy).
The leading directories are created with te default access mode of 0755.
If something else is desired, users should simply declare appropriate
"d" lines.
Fixes: #7853
sd_path_home() returns ENXIO when a variable (such as $XDG_RUNTIME_DIR) is not
defined. Previously we used ENOKEY for unresolvable specifiers. To avoid having
two codes, or translating ENXIO to ENOKEY, I replaced ENOKEY use with ENXIO.
v2:
- use sd_path_home and change to ENXIO everywhere
This commit adds specifiers %U, %u and %h for the user UID, name and
home directory, respectively.
[zj: drop untrue copy-pasted comments and move the next text
to the new "Specifiers" section.
Now that #7444 has been merged, also drop the specifier functions.]
Fixes#4097.
As of current master, systemd-tmpfiles behaves correctly, apart from a trivial
typo. So let's tell github to close the bug.
With current git:
$ sudo SYSTEMD_LOG_LEVEL=debug build/systemd-tmpfiles --create `pwd`/test/tmpfiles.d/link-loop.conf
Successfully loaded SELinux database in 2.385ms, size on heap is 321K.
Reading config file "/home/zbyszek/src/systemd-work/test/tmpfiles.d/link-loop.conf".
Running create action for entry D /run/hello2
Found existing directory "/run/hello2".
"/run/hello2" has right mode 41777
Running create action for entry f /run/hello2/hello2.test
"/run/hello2/hello2.test" has been created.
"/run/hello2/hello2.test" has right mode 101777
chown "/run/hello2/hello2.test" to 0.84
Running create action for entry L /run/hello2/hello2.link
Found existing symlink "/run/hello2/hello2.link".
Running create action for entry z /run/hello2/hello2.test
"/run/hello2/hello2.test" has right mode 101777
chown "/run/hello2/hello2.test" to 0.0
Running create action for entry z /run/hello2/hello2.link
Skipping mode an owner fix for symlink /run/hello2/hello2.link.
and the permissions are:
$ ls -dl /run/hello2/ /run/hello2/*
drwxrwxrwt. 2 foo bar 80 Nov 22 14:40 /run/hello2/
lrwxrwxrwx. 1 root root 23 Nov 22 14:40 /run/hello2/hello2.link -> /run/hello2/hello2.test
-rwxrwxrwt. 1 root root 0 Nov 22 14:40 /run/hello2/hello2.test
Everything seems correct.
The code intentionally ignored unknown specifiers, treating them as text. This
needs to change because otherwise we can never add a new specifier in a backwards
compatible way. So just treat an unknown (potential) specifier as an error.
In principle this is a break of backwards compatibility, but the previous
behaviour was pretty much useless, since the expanded value could change every
time we add new specifiers, which we do all the time.
As a compromise for backwards compatibility, only fail on alphanumerical
characters. This should cover the most cases where an unescaped percent
character is used, like size=5% and such, which behave the same as before with
this patch. OTOH, this means that we will not be able to use non-alphanumerical
specifiers without breaking backwards compatibility again. I think that's an
acceptable compromise.
v2:
- add NEWS entry
v3:
- only fail on alphanumerical
In this way, individual errors in files can be treated differently than a
failure of the whole service.
A test is added to check that the expected value is returned.
Some parts are commented out, because it is not. This will be fixed in
a subsequent commit.
Some filesystems do not set d_type value when
readdir is called, so entry type is unknown.
Therefore check if accessing entry does not
return ELOOP error.
As it turns out MAX_HANDLE_SZ is a lie, the handle buffer we pass into
name_to_handle_at() might need to be larger than MAX_HANDLE_SZ, and we
thus need to invoke name_to_handle_at() in a loop, growing the buffer as
needed.
This adds a new wrapper name_to_handle_at_loop() around
name_to_handle_at() that does the necessary looping, and ports over all
users.
Fixes: #7082
In chroot environments, /etc might not be fully initialized: /etc/machine-id
can be missing for example. This makes the expansions of affected specifiers
impossible at that time.
These cases should not be considered as errors and such failures shouldn't be
logged at an error level therefore this patch downgrades the level used to
LOG_NOTICE in such cases.
Also this is logged at LOG_NOTICE only the first time and then downgrade to
LOG_DEBUG for the rest. That way, if debugging is enabled we get the full
output, but otherwise we only see only one message.
The expansion of specifiers is now self contained in a dedicated function
instead of being spread all over the place.
The advantage is that is the name is mispellt, cpp will warn us.
$ git grep -Ee "conf.set\('(HAVE|ENABLE)_" -l|xargs sed -r -i "s/conf.set\('(HAVE|ENABLE)_/conf.set10('\1_/"
$ git grep -Ee '#ifn?def (HAVE|ENABLE)' -l|xargs sed -r -i 's/#ifdef (HAVE|ENABLE)/#if \1/; s/#ifndef (HAVE|ENABLE)/#if ! \1/;'
$ git grep -Ee 'if.*defined\(HAVE' -l|xargs sed -i -r 's/defined\((HAVE_[A-Z0-9_]*)\)/\1/g'
$ git grep -Ee 'if.*defined\(ENABLE' -l|xargs sed -i -r 's/defined\((ENABLE_[A-Z0-9_]*)\)/\1/g'
+ manual changes to meson.build
squash! build-sys: use #if Y instead of #ifdef Y everywhere
v2:
- fix incorrect setting of HAVE_LIBIDN2
If a path passes though an autofs filesystem, then accessing
the path might trigger and automount. As systemd-tmpfiles is run before
the network is up, and as automounts are often used for networked
filesystems, this can cause a deadlock.
So chase_symlinks is enhance to accept a new flag which tells it
to check for autofs, and return -EREMOTE if autofs is found.
tmpfiles is changed to check just before acting on a path so that it
can avoid autofs even if a symlink was created earlier by tmpfiles
that would send this path through an autofs.
This fixes a deadlock that happens when /home is listed in /etc/fstab as
x-systemd.automount for an NFS directory.
tmpfiles.d option "e" when run through systemd-tmpfiles --create should
apply configured permissions (uid,gid) only to already existing
files. When file doesn't exist we bail out with error. Instead we should
silently ignore non-existing files.
$ useradd test
$ cat /etc/tmpfiles.d/foobar.conf
e /tmp/test - test test 1d
$ ls -l /tmp/test
ls: cannot access '/tmp/test': No such file or directory
Before:
$ systemd-tmpfiles --create /etc/tmpfiles.d/foobar.conf
Adjusting owner and mode for /tmp/test failed: No such file or directory
$ echo $?
1
After:
$ systemd-tmpfiles --create /etc/tmpfiles.d/foobar.conf
$ echo $?
0
Currently if tmpfiles is run with force on symlink creation but there already
exists a directory at that location, the creation will fail. This change
updates the behavior to remove the directory with rm_fr and then attempts to
create the symlink again.
All those uses were correct, but I think it's better to be explicit.
Using implicit errno is too error prone, and with this change we can require
(in the sense of a style guideline) that the code is always specified.
Helpful query: git grep -n -P 'log_[^s][a-z]+\(.*%m'
This filters out "." and ".." from glob results. Fixes#5655 and #5644.
Any judgements on whether the path is "safe" are removed. We will not remove
"/" under any name (including "/../" and such), but we will remove stuff that
is specified using paths that include "//", "/./" and "/../". Such paths can be
created when joining strings automatically, or for other reasons, and people
generally know what ".." and "." is.
Tests are added to make sure that the helper functions behave as expected.
Lennart Poettering