chase_symlinks() would return negative on error, and either a non-negative status
or a non-negative fd when CHASE_OPEN was given. This made the interface quite
complicated, because dependning on the flags used, we would get two different
"types" of return object. Coverity was always confused by this, and flagged
every use of chase_symlinks() without CHASE_OPEN as a resource leak (because it
would this that an fd is returned). This patch uses a saparate output parameter,
so there is no confusion.
(I think it is OK to have functions which return either an error or an fd. It's
only returning *either* an fd or a non-fd that is confusing.)
The force field of the Item struct is used to indicate
force creation or appending in different context. This
change renames the field to append_or_force to improve
readability.
In the light of #12926 I needed some log messages for testing. This
tmpfiles one came to mind, since it's frequently seen on typical Fedora
systems. Alas, they didn't actually use log_syntax, and thus weren't
recognizable by the new config file urlifaction code. Let's fix that.
Whenever I see EXTRACT_QUOTES, I'm always confused whether it means to
leave the quotes in or to take them out. Let's say "unquote", like we
say "cunescape".
prefix_root() is equivalent to path_join() in almost all ways, hence
let's remove it.
There are subtle differences though: prefix_root() will try shorten
multiple "/" before and after the prefix. path_join() doesn't do that.
This means prefix_root() might return a string shorter than both its
inputs combined, while path_join() never does that. I like the
path_join() semantics better, hence I think dropping prefix_root() is
totally OK. In the end the strings generated by both functon should
always be identical in terms of path_equal() if not streq().
This leaves prefix_roota() in place. Ideally we'd have path_joina(), but
I don't think we can reasonably implement that as a macro. or maybe we
can? (if so, sounds like something for a later PR)
Also add in a few missing OOM checks
This makes the code match the docs for --root ("all paths will be prefixed").
I think this is reasonable, because --root also works for config paths, and
any configuration inside --root must refer to paths under --root. If we allowed
C to go "outside of root" in this way, the effect of calling systemd-tmpfiles --root=...
and chrooting first and then calling systemd-tmpfiles second would be quite different.
I think it's better to keep things simple and consistent.
Fixes#12467.
chown() might drop the suid/sgid bit from files. hence let's chmod()
after chown().
But also, let's tighten the transition a bit: before issuing chown()
let's set the file mask to the minimum of the old and new access
bitmask, so that at no point in time additional privs are available on
the file with a non-matching ownership.
Fixes: #12354
This informs chase_symlinks that symlinks should be treated as if
the path given by --root= is the root of their file system.
With the parent commit, this allows tmpfiles to create files as the
root user under a prefix that may be owned by an unprivileged user.
In particular, this fixes the case where tmpfiles generates initial
files in a staging root directory for packaging under a directory
owned by the unprivileged packager user (e.g. in Gentoo).
We potentially might descent into quite deep directory trees. Let's
hence make sure we can allocate a lot of fds.
(This reflects the fact that glibc nftw() and friends have some logic in
place to reduce fd usage while descending into directory trees. Doing so
is a bit nasty I think, and given that fds are basically free now, if we
ask for them, lte's just protect ourselves and make use of that)
(No, I am not aware of a real-world case where this was necessary, but
let's better be safe than sorry)
Let's add a fully safe way to exclude certain directories from aging, by
taking a BSD file lock on them before aging them. This is useful for
clients that untar tarballs into /tmp or /var/tmp, which might have
really old timestamps, and to which the aging logic would be very harsh:
they can simply take a BSD file lock on any directory they like and thus
exclude it from automatic aging, and thus need not to be afraid of
untarring stuff below it.
Previously, similar functionality was already available through the
sticky bit on non-directories, but it's problematic, since as soon as
the bit is set no clean-up is done for it at all anymore, forever. Also,
it is not suitable for untarring stuff, since the sticky bit after all
is a concept denoted in the tarball itself. BSD file locking semantics
are much much nicer there, as they are automatically released when the
application that has them dies, and they are entirely orthogonal to data
encoded in tarballs.
This patch takes BSD file locks only on *directories* while descending
down the tree, not on regular files. Moreover, it will do so in
non-blocking mode only, i.e. if anyone else has a lock the aging for a
dir and everything below it is immediately skipped for the current
clean-up iteration.
Of course applications might take BSD file locks for other reasons than
just prevent aging (i.e for their own reasons), but that should be
entirely OK, as in that case tmpfiles should step away from those files
anyway too: it's a good idea to stay away from any such locked file
anyway since it's apparently curretnly being manipulated.
This allows us to fix bugs like this:
https://github.com/systemd/mkosi/issues/252
It would be very wrong if any of the specfier printf calls modified
any of the objects or data being printed. Let's mark all arguments as const
(primarily to make it easier for the reader to see where modifications cannot
occur).
This has the side effect to upgrade the log level at which the log is emitted
from debug to warning.
This might be better since after all we didn't apply a tmpfiles.d/ rule and
that actually might end up being problematic eventually.
and let's emit a more comprehensive warning when an unsafe transition is
encountered.
Before this patch:
Unsafe symlinks encountered in /run/nrpe, refusing.
After:
Detected unsafe path transition / → /run during canonicalization of /run/nrpe.
We previously returned -EPERM but it can be returned for various other reasons
too.
Let's use -ENOLINK instead as this value shouldn't be used currently. This
allows users of CHASE_SAFE to detect without any ambiguities when unsafe
transitions are encountered by chase_symlinks().
All current users of CHASE_SAFE that explicitly reacted on -EPERM have been
converted to react on -ENOLINK.
Ideally, coccinelle would strip unnecessary braces too. But I do not see any
option in coccinelle for this, so instead, I edited the patch text using
search&replace to remove the braces. Unfortunately this is not fully automatic,
in particular it didn't deal well with if-else-if-else blocks and ifdefs, so
there is an increased likelikehood be some bugs in such spots.
I also removed part of the patch that coccinelle generated for udev, where we
returns -1 for failure. This should be fixed independently.
Pretty much everything uses just the first argument, and this doesn't make this
common pattern more complicated, but makes it simpler to pass multiple options.
Previously, we'd always process parents before children. With this
change we are a bit more careful and create parents before children but
clean up children before parents.
The "done" boolean by item is replaced by a mask so that we can descent
and ascend for the right operations only.
See: #9508
This is an implementation that covers making errors encountered when writing
file content optionally fatal. If this is something that folks would want I'll
add handling of this for all the other directives. I'd appreciate suggestions
on how this might better be structured as well (use of a goto fail or such) as
I'm not super happy with the approach.
A follow-up for commit 9d874aec45.
This patch makes "path" parameter mandatory in fd_set_*() helpers removing the
need to use fd_get_path() when NULL was passed. The caller is supposed to pass
the fd anyway so assuming that it also knows the path should be safe.
Actually, the only case where this was useful (or used) was when we were
walking through directory trees (in item_do()). But even in those cases the
paths could be constructed trivially, which is still better than relying on
fd_get_path() (which is an ugly API).
A very succinct test case is also added for 'z/Z' operators so the code dealing
with recursive operators is tested minimally.
Let's fold get_user_creds_clean() into get_user_creds(), and introduce a
flags argument for it to select "clean" behaviour. This flags parameter
also learns to other new flags:
- USER_CREDS_SYNTHESIZE_FALLBACK: in this mode the user records for
root/nobody are only synthesized as fallback. Normally, the synthesized
records take precedence over what is in the user database. With this
flag set this is reversed, and the user database takes precedence, and
the synthesized records are only used if they are missing there. This
flag should be set in cases where doing NSS is deemed safe, and where
there's interest in knowing the correct shell, for example if the
admin changed root's shell to zsh or suchlike.
- USER_CREDS_ALLOW_MISSING: if set, and a UID/GID is specified by
numeric value, and there's no user/group record for it accept it
anyway. This allows us to fix#9767
This then also ports all users to set the most appropriate flags.
Fixes: #9767
[zj: remove one isempty() call]
This is a bit like the info link in most of GNU's --help texts, but we
don't do info but man pages, and we make them properly clickable on
terminal supporting that, because awesome.
I think it's generally advisable to link up our (brief) --help texts and
our (more comprehensive) man pages a bit, so this should be an easy and
straight-forward way to do it.
The qgroup logic (types 'q' and 'Q') only has an effect if there's no previous
setup at all, and any explicitly configured subvolumes with their qgroups are
left entirely unmodified.
The idea is that if users want a different logic than the one we set up by
default, then by all means they should do that before hand, and tmpfiles won't
override their logic.
fd_get_path() is an ugly API, as it creates ambiguities related to the
" (deleted)" suffix /proc/$PID/fd/$FD shows. Let's use it a bit less
excessively, and whenever we have a good valid path already, let's
simply pass that along, instead of forgetting it in one stackframe and
reacquiring it in the next.
Since all path_set_*() helpers don't follow symlinks, it's possible to use
chase_symlinks(CHASE_NOFOLLOW) flag to both open the files specified by the
passed paths and check their validity (unlike their counterpart fd_set_*()
helpers).
TRUNCATE_FILE is now handled by a new dedicated function
truncate_file(). Indeed we have to take special care when truncating existing
file since the behavior is only specified for regular files.
Well that's not entirely true for fifo and terminal devices since O_TRUNC is
ignored in this case but even in for these types of file, truncating is
probably not the right thing to do.
It is worth noting that both truncate_file() and create_file() have been
modified so they use fstat(2) instead of stat(2) since both functions are not
supposed to follow symlinks.
Zach Smith