IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
All dbus programs have to be up-to-date for update-dbus-docs to
produce the expected output, so add the missing dependency.
(cherry picked from commit 461bd9277a69833a534518c263d00443f2f6fbf4)
(cherry picked from commit cd727da491f0715995f06f3ad7e6e2ec2ab2e44a)
(cherry picked from commit c5e562c8eeb81f9573bd14446ad77c43f5b73d7a)
While this is obvious if you spend a few minutes thinking about how
D-Bus signals work (in this case, they are broadcast from a system
service, so cannot apply to a specific user/session/seat), it’s a bit
easy to overlook this while putting code together which uses the login1
D-Bus API, so it’s helpful to point this hazard out specifically in the
docs.
The signals can only be emitted on the canonical objects. The
convenience objects are useful for method calls, as the calling context
can be used to dereference ‘self’ and ‘auto’, but this can’t work for
signals.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
(cherry picked from commit 82b32b997c51e259ddf66a0ec6bd7631b0ea781d)
(cherry picked from commit afc6244bb1accde277359e3aa7b1976cc96080cf)
(cherry picked from commit aa560dbadced069da9d3c44cf3a352435a782b31)
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
(cherry picked from commit 5fe4edd3fccd2a14ec3488daeac80ddb33bc71db)
(cherry picked from commit 8ef9fdf79bfa852898a569a9032faa1dafe8c6c1)
(cherry picked from commit be45ace625bcbfe0a91966d16c447f9ebf2b5f85)
UKIs should generally not be compressed since the kernel image and
initrd in them will already be compressed so let's remove the compression
suffix from the examples in the sysupdate manpage.
(cherry picked from commit 5ca1865ad95a10b744321d21293587ed1d446ee6)
(cherry picked from commit 9440a08ccce6c5ebb5091a38dd709737a4ae22b9)
(cherry picked from commit 082fab587bef69adf30c2950e5a59a92c78021c8)
'ConditionOSRelease=|ID_LIKE$=*rhel*' results in a segfault.
The key 'ID_LIKE' is not present in Fedora's os-release file.
I think the most reasonable behaviour is to treat missing keys as empty.
This matches the "shell-like" sprit, since in a shell empty keys would
by default be treated as empty too. Thus, "ID_LIKE=" would match, if
ID_LIKE is not present in the file, and ID_LIKE=!$foo" would also match.
The other option would be to make those matches fail, but I think that'd
make the feature harder to use, esp. with negative matches.
Documentation is updated to clarify the new behaviour.
https://bugzilla.redhat.com/show_bug.cgi?id=2345544
(cherry picked from commit de02b551adcf74e5677454fd36bf7653b1a4def1)
(cherry picked from commit 8f8514c03f166c352ebdcb577c29d2dff88a37f7)
(cherry picked from commit f36638fbd262f79b334f0f4cf8f0d056458d30ae)
(cherry picked from commit 2443b4d9a17787fd0a63d6591fbdb74650c43994)
(cherry picked from commit e8d5d7f355ae826f4f8c0f61f62c31e828bde7d0)
(cherry picked from commit 34eb74020f77ddc3635bfc489198fe18d123cdb7)
(cherry picked from commit df9c5c1c9c230605734aeace4cd3861ff3d6ee6d)
(cherry picked from commit e24bc34ed8dc5a663344c2a6468d820431bbd4ea)
(cherry picked from commit f7ef06102598a84e30fbffb71147db0cddd38358)
The UKI file has to be writable to be able to do boot counting in
the UEFI firmware which involves renaming the file by writing to
the file metadata which requires the file to be writable in the FAT
filesystem.
Fixes#36170
(cherry picked from commit 0e470e1cc32776f7b57f57640193d6dd0df97a5b)
(cherry picked from commit 7358b67ad1e2eb865bd5628ff6c20a13439ff3d0)
(cherry picked from commit dcffc79b27b263427172185b8ff69d5f655f245b)
(cherry picked from commit 3e1d7b6aae5f5b24610620db810a5730dcc9a6a6)
(cherry picked from commit e5bf5f0d6101acb818e76083c9b48ecf6e9e015e)
(cherry picked from commit a041c5398c30a58eda17256ac29f4628ebfb795b)
(cherry picked from commit 390dffb862af5791a33abef08011f87818249975)
(cherry picked from commit a3474965b68c1bc4b3e137eee03408f2a577b2a1)
(cherry picked from commit edae23869f1b5bb825527e4b6655a6c08693883f)
Let's clarify more explicitly that privileged calls to
systemd-notify --pid= and sd_pid_notify() effectively override any
configured NotifyAccess=main|exec for a service.
(cherry picked from commit bbe9e03f8066d1001497494ee862cf45f986b854)
(cherry picked from commit 9b186fc8bc039d76d4667f92437d9ff1464d76fe)
(cherry picked from commit 196bd85b3ee3ea0bd783ee8c2c675bf67883e470)
In the example from systemd-measure(1), do not bind to PCR 7 in
addition to the PCR policy.
As long as this is still done by default, see #35280.
(cherry picked from commit 693038fce47a819c5eebeb4fce39c9ac991acf84)
(cherry picked from commit 926f5ab6bf0e3541106e6a6f95af4cbdec50582b)
(cherry picked from commit dc073e69a9a56a4f1b8de8d921acdf026d21bc37)
Otherwise it doesn't hold that VLANs 100-400 are allowed (because 201-299 are disallowed).
(cherry picked from commit ae2f3af63962ba6e2f67cfce07c9fee61722e30e)
(cherry picked from commit 9fad72cc52bdec7f44337b1e48c23ee15fc08d77)
(cherry picked from commit 0102ff403ee230bdd7a0c2b38463d9292fb9c0ae)
Document the fact that read-only properties may not have the flag
SD_BUS_VTABLE_UNPRIVILEGED as that is not obvious especially given the
flag is accepted for writable properties.
Based on the check in `add_object_vtable_internal` called by
`sd_bus_add_object_vtable` (as of the current tip of the main branch
f7f5ba019206cacd486b0892fec76f70f525e04d):
case _SD_BUS_VTABLE_PROPERTY: {
[...]
if ([...] ||
[...]
(v->flags & SD_BUS_VTABLE_UNPRIVILEGED && v->type == _SD_BUS_VTABLE_PROPERTY)) {
r = -EINVAL;
goto fail;
}
(where `_SD_BUS_VTABLE_PROPERTY` means read-only property whereas
`_SD_BUS_VTABLE_WRITABLE_PROPERTY` maps to writable property).
This was implemented in the commit
adacb9575a09981fcf11279f2f661e3fc21e58ff ("bus: introduce "trusted" bus
concept and encode access control in object vtables") where
`SD_BUS_VTABLE_UNPRIVILEGED` was introduced:
Writable properties are also subject to SD_BUS_VTABLE_UNPRIVILEGED
and SD_BUS_VTABLE_CAPABILITY() for controlling write access to them.
Note however that read access is unrestricted, as PropertiesChanged
messages might send out the values anyway as an unrestricted
broadcast.
(cherry picked from commit 3ca09aa4dd57327989eceb1298754601046ac041)
(cherry picked from commit cd727031a4daafe19f491df360c512433562f469)
(cherry picked from commit f694a84faf082ce4a18cc2478d7843bb2b7e7fc4)
Fixes https://github.com/systemd/systemd/issues/28514.
Quoting https://github.com/systemd/systemd/issues/28514#issuecomment-1831781486:
> Whenever PAM is enabled for a service, we set up the PAM session and then
> fork off a process whose only job is to eventually close the PAM session when
> the service dies. That services we run with service privileges, both to
> minimize attack surface and because we want to use PR_SET_DEATHSIG to be get
> a notification via signal whenever the main process dies. But that only works
> if we have the same credentials as that main process.
>
> Now, if pam_systemd runs inside the PAM stack (which it normally does) it's
> session close hook will ask logind to synchronously end the session via a bus
> call. Currently that call is not accessible to unprivileged clients. And
> that's the part we need to relax: allow users to end their own sessions.
The check is implemented in a way that allows the kill if the sender is in
the target session.
I found 'sudo systemctl --user -M "zbyszek@" is-system-running' to
be a convenient reproducer.
Before:
May 16 16:25:26 x1c systemd[1]: run-u24754.service: Deactivated successfully.
May 16 16:25:26 x1c dbus-broker[1489]: A security policy denied :1.24757 to send method call /org/freedesktop/login1:org.freedesktop.login1.Manager.ReleaseSession to org.freedesktop.login1.
May 16 16:25:26 x1c (sd-pam)[3036470]: pam_systemd(login:session): Failed to release session: Access denied
May 16 16:25:26 x1c systemd[1]: Stopping session-114.scope...
May 16 16:25:26 x1c systemd[1]: session-114.scope: Deactivated successfully.
May 16 16:25:26 x1c systemd[1]: Stopped session-114.scope.
May 16 16:25:26 x1c systemd[1]: session-c151.scope: Deactivated successfully.
May 16 16:25:26 x1c systemd-logind[1513]: Session c151 logged out. Waiting for processes to exit.
May 16 16:25:26 x1c systemd-logind[1513]: Removed session c151.
After:
May 16 17:02:15 x1c systemd[1]: run-u24770.service: Deactivated successfully.
May 16 17:02:15 x1c systemd[1]: Stopping session-115.scope...
May 16 17:02:15 x1c systemd[1]: session-c153.scope: Deactivated successfully.
May 16 17:02:15 x1c systemd[1]: session-115.scope: Deactivated successfully.
May 16 17:02:15 x1c systemd[1]: Stopped session-115.scope.
May 16 17:02:15 x1c systemd-logind[1513]: Session c153 logged out. Waiting for processes to exit.
May 16 17:02:15 x1c systemd-logind[1513]: Removed session c153.
Edit: this seems to also fix https://github.com/systemd/systemd/issues/8598.
It seems that with the call to ReleaseSession, we wait for the pam session
close hooks to finish. I inserted a 'sleep(10)' after the call to ReleaseSession
in pam_systemd, and things block on that, nothing is killed prematurely.
(cherry picked from commit fc0bb7ccc763ec79efe7a8a58220e9bc80f34f81)
Resolves https://bugzilla.redhat.com/show_bug.cgi?id=2221337.
This page contains many short example codes. I do not think we should
add SPDX-License-Identifier for all codes.
Closes#35356.
(cherry picked from commit 6046cc3660810efcc6fe50b1c850ea642218245b)
(cherry picked from commit 6f2483eed8d790b94945aece37833c3604e3fc11)
Processes can easily survive the first kill operation we execute, hence
we shouldn't make strong claims about them having exited already. Let's
just say "likely" hence.
Fixes: #15032
(cherry picked from commit ac804bc2f8d814d2afcdccd88f7469ac320da1c8)
(cherry picked from commit 307a6332a63dd0f6addbc5c77d21f72ce4578070)
The documentation claimed that ExecStartPre=/ExecStartPost= accepts
multiple command lines, in contrast to ExecStart=. This is half an
untruth, because ExecStart= allows that too – as long as Type=oneshot is
set.
Hence, reword this a bit, and do not emphasize the contrast.
Prompted by: #34570
(cherry picked from commit c3069a6bfb454a0e02607ad21b5badf9847fe11a)
(cherry picked from commit ff667d8c2ef7ed2378fb1de39e1bcc2af2197d0e)
Avoids the need to maintain the same list over and over again, and
link it to the defition table in the implementation as a reminder
too
(cherry picked from commit 3509fe124d3a4fe2934028f83ae156ade050c8fe)
(cherry picked from commit 1075727f7fe9436d2e468147cf663aaa1be867fd)
We had several users, that wrote their unit files with
WantedBy=default.target because it should be started "every time".
But for example in Fedora/CentOS/RHEL, this often breaks for
example selinux relabels (where we just want to do a relabel and reboot).
(cherry picked from commit 67b6404b80cf8078f3d9ec6d4c2f34ac25b15077)
(cherry picked from commit adc57cd81c02e5afc8efcbc64eb3a6305a97c62c)
We don't support "split /usr" systems anymore, hence no point in
mentioning /bin/ anymore as being part of the binary search path.
(cherry picked from commit f39e66b85a4a97818a618758e34019d052aeb772)
(cherry picked from commit 96c0549bda0c2fc682a9dee308ad1a90d2ebd422)
So far we supported this syntax:
ExecStart=foo ; bar
as equivalent to:
ExecStart=foo
ExecStart=bar
With this change we'll "soft" deprecate the first syntax. i.e. it's
still supported in code, but not documented anymore.
The concept was originally added to make things easier for 3rd party
.ini readers, as it allowed writing unit files with a .ini framework
that doesn't allow multiple assignments for the same key. But frankly,
this is kinda pointless, as so many other of our knobs require the
double assignment.
Hence, let's just stop advertising the concept, let's simplify the docs,
by removing one entirely redundant feature from it.
Replaces: #34570
(cherry picked from commit 225f18b9a9d39331ea862478ab2ff893678e249d)
(cherry picked from commit aeda397aedc02d32672cb10402b0b63e64b7a17e)
fix pointer constness in documentation
(cherry picked from commit fec09ff094670a6903b12b1c599b00b39a2b0c88)
(cherry picked from commit 072ea04e26c84ac25419316c659f4d89d8002f34)
Just to tighten the language a bit, why people should care about where
they place their inodes.
(cherry picked from commit 5b53894123b9d01f5738b02befd4189625c5451f)
(cherry picked from commit 4bdbfb3dd4c45720357d066fa8e4f65bccc610f6)
(And specifically mention /usr/include + /var/spool as not covered here,
but being OK to add downstream)
(cherry picked from commit fd6e079e7b296696028c161224d2a86fce70726f)
(cherry picked from commit c14890f588745a87c7b4a9a7ed0991e03a7b91ea)
Today it seems this is mostly used by mail and printer servers, and it's
not clear to me at all what the property is that makes
/var/spool/<package> the better place for the relevant data than
/var/lib/<package>.
Hence, in the interest of shortening the spec, let's not mention the dir
anymore. In particular as the dir really isn't used by us much, for
example we do not have a counterpart for RuntimeDirectory=,
StateDirectory=, … that would cover the spool.
Since most systems these days we care about probably come *without* a
printer or mail server, let's maybe no mention this in the man page that
is supposed to discuss the rough skeleton how things are set up. After
all, people are supposed to exend the skeleton with their stuff, and
this sounds more like a case for an extension of the skeleton instead of
being considered part of the skeleton itself.
(cherry picked from commit b0201b36d2e0181d08530aaad496322812c4e77e)
(cherry picked from commit 82783a3c5fd262c9006a5f9091a4875b1dad1c5a)
The man page is supposed to provide a "generalized, though minimal and
modernized subset" (as per introductory pargapraghs), from a systemd
perspective. But the thing is that /usr/include/ really doesn't matter
to us. It's a development thing, and slightly weird (because it arguably
would be better places in /usr/share/include/ or so). It's not going to
be there on 95% of deployed systems, and we really don't want people to
bother with it on such systems.
We only define the skeleton of directories in this document, and it's
expected that people extend it, and I think this really should be one of
those dirs that is an extension of our skeleton, but not part of the
skeleton, if that makes any sense.
(cherry picked from commit 9e7b691073922433a71cf49dcaaf7f9f61f58e6d)
(cherry picked from commit e5ac408af76ca1b6827de08a1960970a7d8db15d)
Somebody wrapped the text, but whitespace is preserved in <programlisting>, so
the output was mangled. It also doesn't make sense to run systemd-path as root
(as indicated by '#'), so drop that. Also, this chunk should be a separate
paragraph.
(cherry picked from commit 1ca81b2e005ccef6e9ddf06c3e3441bae0a6e1d5)
(cherry picked from commit 53b5032ffdb4f619560d69d033ef309784c41f1f)
We generally do _not_ want the same sysexts to be loaded in both initrd and
exitrd phases. The environment is completely different and it's unlikely that
the same code can be useful in both places. Nevertheless, it can be useful in
_some_ cases, for example when the sysexts contains debugging tools.
I think we don't need to differentiate between initrds and exitrds through
SYSEXT_SCOPE, because the two types are made available in completely different
locations and loaded through a different mechanism, with very little chance of
an initrd being loaded as an exitrd without an explicit admin action (or the
other way around). So let's not complicate our code or definitions by an
explicit "exitrd" sysext designator, but just clarify that "initrd" also
encompasses exitrds in this context.
(cherry picked from commit 7352a0093f4ef96c361be22337cde3296d79da01)
(cherry picked from commit 2cd8079efabb8f17e6e58f1fd6c051d388648146)
The concept is fairly well established and present in our docs in various
places.
Say that the exitrd is also marked by the presence of /etc/initrd-release.
(cherry picked from commit ace26a511ff63dbc15f1b2b0b941cbd3294a288c)
(cherry picked from commit b78f99e71b5ffa57caa5508e871ba17a6ff686d7)
Bit 60 is the one corresponding to ReadOnly, not 50. Fix this.
(cherry picked from commit 932cc94436e653d0487c29e0dd44685610cd7bcb)
(cherry picked from commit 2665618555d08fc3877043cac392f1b6573811b7)
Follow-up for af7417ac7b07bc01232982bf46e9d72e69e7f820.
Closes#33596.
(cherry picked from commit 1c0130e8dc3c99d5a85be41e9172adb0ff0cf7fd)
(cherry picked from commit ce940b62acfca1f229818d82edee07986c05b50c)
Prompted by #33702.
(cherry picked from commit 347c8822d1a8a5b70624920b3de2a91d4e0fca91)
(cherry picked from commit ab4e1faca6e5128a3c32d93eedd5609709da8229)
Add a section which lists the known confidential virtual machine
technologies.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit a8fb5d21fd6127a6d05757c793cc9ba47f65c893)
(cherry picked from commit 037510812fbcaf689b5b107a85f3a031d15dc505)
- Improve wording for explanation when these variables are inherited
- Clarify that these variables are not placed in the process environment block,
so /proc/PID/environ cannot be used as a debugging tool
(cherry picked from commit 6c1e0823b04525716d9ee0031a2b6735d3f7dfa4)
(cherry picked from commit 5cf0c45f64079430b0b7c12ad323f238386260b0)
This fixes
commit 9b0688f491674b53ef7a52bdf561a430c53673d6
Author: Yu Watanabe <watanabe.yu+github@gmail.com>
Date: Tue Jan 9 10:52:49 2024 +0900
virt: add Google Compute Engine support
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 9ffdfc67c6aedcb66c2b18c2c61bc32e585e6d6e)
(cherry picked from commit b077417713ea6df028d61287c042abc235fc0c41)
The page was written when systemd-repart was primarily intended to be used on a
running system. But nowadays it's more often used to create images, so extend
that part of the description.
While at it, fix some whitespace issues and trim some overly complicated sentences.
(cherry picked from commit d202ea57549248c4246c8f453a2ff88a4c2a7e1e)
(cherry picked from commit e60d01bdbf0d31d32d4bf1e36d5c40e16c84fafb)
