This was probably a typo, since depending proxy-to-nginx.service on
itself makes no sense, but depending on the socket does.
Signed-off-by: Roland Hieber <r.hieber@pengutronix.de>
It is possible that kernel will reject our netlink message that
configures the link. However, we should always make sure that interface
will be named properly otherwise we can leave interfaces having
unpredictable kernel names. Thus we don't return early and continue to
export name and link file properties.
Suggested-by: Tom Gundersen <teg@jklm.no>
SetLinger is authorized by the PolicyKit action "set-self-linger", if it is
not passed an explicit UID.
According to comments we were determining the default UID from the client's
session. However, user processes e.g. which are run from a terminal
emulator do not necessarily belong to a session scope unit. They may
equally be started from the systemd user manager [1][2]. Actually the
comment was wrong, and it would also have worked for processes
started from the systemd user manager.
Nevertheless it seems to involve fetching "augmented credentials" i.e.
it's using a racy method, so we shouldn't have been authenticating based
on it.
We could change the default UID, but that raises issues especially for
consistency between the methods. Instead we can just use the clients
effective UID for authorization.
This commit also fixes `loginctl enable-linger $USER` to match the docs
that say it was equivalent to `loginctl enable-linger` (given that $USER
matches the callers user and owner_uid). Previously, the former would not
have suceeded for unpriviliged users in the default configuration.
[1] It seems the main meaning of per-session scopes is tracking the PAM
login process. Killing that provokes logind to revoke device access. Less
circularly, killing it provokes getty to hangup the TTY.
[2] User units may be started with an environment which includes
XDG_SESSION_ID (presuambly GNOME does this?). Or not.
To maintain consistency with `loginctl user-status`, drop the fallback to
XDG_SESSION_ID for `loginctl enable-linger`. The fallback was unnecessary
and also incorrect: it passed the numeric value of the session identifier
as a UID value.
The manpages tell that such calls have quite limited meaning. logind has
a few in the implementation of what remains of the session concept.
At the same time, logind basically exposes sd_pid_get_session() as public
API. This is absolutely required, to retain compatability e.g. with Xorg.
But client code will work in more situations if it avoids assuming that it
runs in a session itself.
Its use inside the login session could be replaced with $XDG_SESSION_ID
(which pam_systemd sets). I don't know whether it would be useful to
change Xorg at this point or not. But if you were building something new,
you would think about whether you want to support running it in a systemd
service.
Comment these logind API features, acknowledging the reason they exist is
based in history. I.e. help readers avoid drawing implications from their
existence which apply to history, but not the current general case.
Finally, searching these revealed a call to sd_pid_get_session() in
implementing some types of logind inhibitors. So these inhibitors don't
work as intended when taken from inside a systemd user service :(. Comment
this as well, deferring it as ticket #6852.
If you try to run `loginctl user-status` on a non-logged in user to see
whether "Linger" is enabled, it doesn't work.
If you're already an expert in logind, the fact that the user is considered
unknown actually tells you the user is not lingering. So, probably they
they do not have lingering enabled. I think we can point towards this
without being misleading.
I also reword it because I thought it was slightly confusing to run
`loginctl user-status root` and get an error back about "User 0". Try to
be more specific, that it is "User ID 0".
It's confusing that the bus API has aliases like "session/self" that return
an error based on ENXIO, when it also has methods that return e.g.
NO_SESSION_FOR_PID for the same problem. The latter kind of error includes
more specifically helpful messages.
"user/self" is the odd one out; it returns a generic UnknownObject error
when it is not applicable to the caller. It's not clear whether this was
intentional, but at first I thought it was more correct. More
specifically, user_object_find() was returning 0 for "user/self", in the
same situations (more or less) where user_node_enumerator() was omitting
"user/self". I thought that was a good idea, because returning e.g. -ENXIO instead
suggested that there _is_ something specific on that path. And it could be
confused with errors of the method being called.
Therefore I suggested changing the enumerator, always admitting that there
is a handler for the path "foo/self", but returning a specific error when
queried. However this interacts poorly with tools like D-Feet or `busctl`.
In either tool, looking at logind would show an error message, and then go
on to omit "user/self" in the normal listing. These tools are very useful,
so we don't want to interfere with them.
I think we can change the error codes without causing problems. The self
objects were not listed in the documentation. They have been suggested to
other projects - but without reference to error reporting. "seat/self" is
used by various Wayland compositors for VT switching, but they don't appear
to reference specific errors.
We _could_ insist on the link between enumeration and UnknownObject, and
standardize on that as the error for the aliases. But I'm not aware of any
practical complaints, that we returned an error from an object that didn't
exist.
Instead, let's unify the codepaths for "user/self" vs GetUserByPid(0) etc.
We will return the most helpful error message we can think of, if the
object does not exist. E.g. for "session/self", we might return an error
that the caller does not belong to a session. If one of the compositors is
ever simplified to use "session/self" in initialization, users would be
able to trigger such errors (e.g. run `gnome-shell` inside gnome-terminal).
The message text will most likely be logged. The user might not know what
the "session" is, but at least we'll be pointing towards the right
questions. I think it should also be clearer for development / debugging.
Unifying the code paths is also slightly helpful for auditing / marking
calls to sd_bus_creds_get_session() in subsequent commits.
GetSessionByPID(0) can fail with NO_SESSION_FOR_PID. More obscurely, if
the session is abandoned, it can return NO_SUCH_SESSION. It is not clear
that the latter was intended. The message associated with the former,
hints that this was overlooked.
We don't have a document enumerating the errors. Any specific
error-handling in client code, e.g. translated messages, would also be
liable to overlook the more obscure error code.
I can't see any equivalent condition for GetUserByPID(0). On the other
hand, the code did not return NO_USER_FOR_PID where it probably should.
The relevant code is right next to that for GetSessionByPID(0), so it will
be simpler to understand if both follow the same pattern.
PR #7186 changes requires_mounts_for from strv to Hashmap.
So, it is necessary to implement a function for getting the property RequiresMountsFor=.
This introduces property_get_requires_mounts_for() which reads the Hashmap
and sends messages to bus.
Fixes#7321.
If you use machinectl to bind a file into a container, it responds with a confusing error message about a temporary directory not being a directory.
I just swapped it to error with the source that was passed, rather than the tmpdir.
It would also be nice to be able to bind files, but that's a separate issue (#7195).
Before the change:
root@epona /var/lib/sandbox $ cat bar/foo
Hello world!
root@epona /var/lib/sandbox $ machinectl bind testing /var/lib/sandbox/bar/foo /foo
Failed to bind mount: Failed to overmount /tmp/propagate.W5TNsj/mount: Not a directory
After the change:
root@epona /var/lib/sandbox $ machinectl bind testing /var/lib/sandbox/bar/foo /foo
Failed to bind mount: Failed to overmount /var/lib/sandbox/bar/foo: Not a directory
Let's reduce the amount of noise a bit, there's little point in
complaining loudly about every single unit like this, let's complain
only about the first one, and then downgrade the log level to LOG_DEBUG
for the other cases.
Fixes: #7188
This didn't work during the initial conversion to meson, but should now.
A sufficiently new polkit is also required, for the .its rules files.
Note that https://github.com/mesonbuild/meson/blob/master/docs/markdown/i18n-module.md
says that 'install' argument was added in meson 0.43.0. If this is accurate,
warnigs might be generated with older mesons. Fedora has 0.43.0 across the
board, but other distros probably don't, but I guess that a warning is
prefereable to having to update do latest meson.
The advantages are:
- one less dependency (intltool)
- using the generic implementation instead of our open-coded calls
- we don't need to use the fake "_" prefixes in XML
Replaces #1609, fixes#7300.
It's not systemd that invokes the service internally as needed, it's
systemd-localed. Correct that.
Also, stop using the word "helper". To me a "helper" constitutes
something internal, not official API. I doubt systemd-vconsole-setup
really matches that description though, hence let's better avoid the
term.
Also, clean up some other wording, and be less imbiguous, by suggesting
a single command to apply vconsole.conf instead of two.
Follow-up for 597c25d2a7
We already print it as part of log_syntax() internal logic, don't print
it again, and in particular, don't print it at the end of log line, such
a strange place.
Follow-up for: 142468d895
So far, we assumed that kernels where TRIE was on also supported
BPF/cgroup stuff. That's not a correct assumption to make, hence check
for both features separately.
Fixes: #7054
Previously it was not possible to select which controllers to enable for
a unit where Delegate=yes was set, as all controllers were enabled. With
this change, this is made configurable, and thus delegation units can
pick specifically what they want to manage themselves, and what they
don't care about.
Otherwise it's a pointless excercise, as we'll set up an empty directory
tree that's never going to be used.
Hence, let's move this around a bit, so that we do the basesystem
initialization exactly when RootImage= or RootDirectory= are used, but
not otherwise.
When compiling with an old kernel on architectures for which the
number is not defined in missing.h, a warning is generated in missing.h.
Let's just skip the protection in this case, to allow build to proceed.
MemoryDenyWriteExecution policy could be be bypassed by using pkey_mprotect
instead of mprotect to create an executable writable mapping.
The impact is mitigated by the fact that the man page says "Note that this
feature is fully available on x86-64, and partially on x86", so hopefully
people do not rely on it as a sole security measure.
Found by Karin Hossen and Thomas Imbert from Sogeti ESEC R&D.
https://bugs.launchpad.net/bugs/1725348
Let's clarify that it's not networkd that renames interfaces, but
something else (for example, udev's link builtin based on .link files)
This doesn't change any logic, it just rewords the message a bit, to
clarify that we only log this for informational purposes, not because we
execute the rename operation ourselves.
Fixes: #7143
Fix loginctl seat sysfs tree ellipsation logic.
Simple reproducer:
loginctl --full seat-status seat0|cat
→ after this PR, all lines are shown in full. Before, lines were ellipsized to terminal width.
