We would use alloca to extend the format string with "\n". We do this
automatically in order to not forget appending the newline everywhere.
We can simplify the whole thing by using a macro to append the newline instead,
which means that we don't need to copy the string.
Because we concatenate the string argument with another literal string, we know
it must a literal string. Thus it's not a problem that it is "evaluated" two
times.
Quoting Hristo Venev:
> Since commit f5e757f1ce, mhd_respond() adds a
> newline to its argument before passing it on to mhd_respond_internal(). This
> is done via an alloca()-allocated buffer. However, MHD_RESPMEM_PERSISTENT is
> given as a flag to MHD_create_response_from_buffer(), leading to a
> use-after-free later when the response is sent. Replacing
> MHD_RESPMEM_PERSISTENT with MHD_RESPMEM_MUST_COPY appears to fix the issue.
MHD_RESPMEM_MUST_COPY would work, but we also use mhd_respond() for mhd_oom(),
and we don't want to allocate in an oom scenario in order to maximize the
possibility that an answer will be delivered. Using the macro magic makes this
nicer and we get rid of the code doing alloca.
Fixes an issue reported by Hristo Venev.
Fixes https://github.com/systemd/systemd/issues/9858.
According to SPC4, the value of 0x14 is reserved to distinguish
host managed zoned block, e.g., some SMR (Shingled Magnetic Recording)
disks.
Other utilities such as sg3_utils can successfully recognize such
kind of disks. This patch implements the same ability.
Let's make sure these follow the rest of kernel-install and always
operate on the given root directory, even if the verb itself can't
support --root= just yet.
We only want to do this for fully set up, interactive sessions, i.e.
user and user-early, but not for any others, hence restrict the rules a
bit.
Follow-up for: 508b4786e8
In logind we generally want to stop user@.service for a user once they
log out. So the usual rule is that whenever a User object is around that
has no pinning sessions we should close it.
Except that it isn't that easy. We allow that user@.service is also
manually started, in which case the User object is created but not
pinned by any session.
Let's rework how this is handled: we define two different GC modes. In
one GC mode we'll keep the User object around whenever *any* session
exists (thus: including the user@.service session), and one where we
only keep it around whenever a *pinning* session exists (i.e. when a
user actually logs in, but the user@.service session doesn't count like
that).
And the trick is now that we start out in the *any* GC mode, and switch
to the *pinning* GC mode once the first user session logs in.
This should make things more robust as we know exactly in which state we
are and when to GC a user.
Let's streamline the logic that decides whether the screen lock, idle
timeout or display election mechanism applies to a session class. Let's
add explicitly SESSION_CLASS_IS_XYZ() macros for each, and then resue
them at all suitable places, and refuse any attempts to use the
functionality on the wrong clases with a friendly error message.
This is the same as the "background" class, but does *not* pull in a
service manager. It might be useful for things like select cron jobs
that do not intend to call per-user IPC calls.
Replaces: #23569Fixes: #23978
Previously, all user code was part of a session except for the code run
as part of user@.service, which wasn't. This tries to make this more
uniform: we'll track the user@.service runtime also as a session, but of
the special type "manager".
This means we have a really good overview finally of all user code that
is running and can make decisions on what to start when and how long to
keep it around. The pam_systemd client side will now be reasonably
uniform: it just calls the CreateSession() bus call with the right
class, and we'll return any data it needs. This means the weird
"side-channel" we previously used to initialize XDG_RUNTIME_DIR for the
user@.service goes away (see next commit).
This conditionalizes various behaviours now cleanly depending on the
session class:
1. SESSION_CLASS_WANTS_SCOPE() will be true for all classes except for
the manager class. It declares whther the client shall be migrated
into their own scope, which we generally want for sessions but not
for the manager, since it already has its own service unit.
2. SESSION_CLASS_WANTS_SERVICE_MANAGER() will be true for all classes
except for the manager class. It declares whether we shall start the
service manager if a session of this class is around. Of course, this
is off for the service manager, since this would always pin itself.
3. SESSION_CLASS_PIN_USER() will be true for all classes except for the
manager class. It declares whether the we shall keep the User
structure around for a user as long as the session is around.
Now you might wonder why have these as three functions, even though they
mostly give the same answers?
That's because this all is preparation to add further session classes
later that will return different answers for the three calls. (For
example, a later patch adds "background-light" which will return true
for SESSION_CLASS_WANTS_SCOPE() and SESSION_CLASS_PIN_USER(), but false
for SESSION_CLASS_WANTS_SERVICE_MANAGER(). i.e. it will get a scope, and
pin user tracking, but not start a service manager.
This adds a tiny binary that is hooked into SSH client config via
ProxyCommand and which simply connects to an AF_UNIX or AF_VSOCK socket
of choice.
The syntax is as simple as this:
ssh unix/some/path # (this connects to AF_UNIX socket /some/path)
or:
ssh vsock/4711
I used "/" as separator of the protocol ID and the value since ":" is
already taken by SSH itself when doing sftp. And "@" is already taken
for separating the user name.
Without `--root` or `--image`, the `security` command inspects all currently
loaded service units if no unit name is specified. But with `--root` or
`--image` with `--offline=true`, the `security` command exits silently if no
unit name is specified.
Also, fixed description of `--root` and `--image` in the man page, and added
missing `--unit` option to help text.
The data may be from user input or file. We usually use assertion for
programming error. Hence, using assert is not a good choise there.
Preparation for later commits.
In some rare cases, a watchdog driver might neither be able to change
the watchdog timeout value, nor read it from the hardware at runtime.
With an otherwise functional watchdog setup, this constellation worked
until systemd v249. Since then, systemd ends up ignoring the timeout
defined by the system.conf and rather uses USEC_INFINITY. Consequently,
the watchdog is not pinged anymore and eventually resets the system.
We therefore want to ensure that the system keeps running with the
originally configured timeout.
