h than trying
to put selinux labels on everything and hoping the selinux policy is
carefully written enough to understand which inode is which and
prohibit access.
While it is certainly possibly to fuck up the namespacing thing
(simply by not turning it on for a service), I do believe it is much
ha
community patches
to work nicely, because none of the systemd upstream developers use it
(at least to my knowledge).
(I am also not strictly opposed to just copying the label over, but
that'd require a patch to be submitted, and someone from the selinux
upstream folks needs to OK that, but that might be hard to get)
Lennart
--
Lennart Poettering, Berlin
sesment counter, or change the order-id during runtime, which I think its
> very important as we are talking signed+measured efi files, which means we
> cant alter anything on them after their creation. Type 1 gives more
> flexibility in this aspect IMHO.
sd-boot style assesment counters work the same for type 1 and type 2?
In type 1 case the .conf file is renamed, in type 2 case the .efi file
is renamed?
Lennart
--
Lennart Poettering, Berlin
On Di, 23.09.25 16:25, Itxaka Serrano Garcia (itxaka.gar...@spectrocloud.com)
wrote:
> On Tue, Sep 23, 2025 at 4:11 PM Lennart Poettering
> wrote:
>
> > On Di, 23.09.25 09:26, Itxaka Serrano Garcia (
> > itxaka.gar...@spectrocloud.com) wrote:
> >
> > > Als
meterize it somehow, and give it
> > a different title.
> >
> > If you just want to use the embedded data of the type 2, then why use
> > a type 1 at all?
> >
> > Lennart
> >
> > --
> > Lennart Poettering, Berlin
> >
>
> In our case
If you just want to use the embedded data of the type 2, then why use
a type 1 at all?
Lennart
--
Lennart Poettering, Berlin
rectories. Also, I would like to use `DynamicUser=`
> for everything where that is possible.
For the sockets you could put them in some special dir somewhere
then bind mount them via BindReadOnlyPaths=...
Lennart
--
Lennart Poettering, Berlin
s useful for enumeration and subscription, and for
"agent registration" scenarios.
Knowing pam_conv a bit I don't think it should be much of a problem
mapping that 1:1 to varlink requests.
Lennart
--
Lennart Poettering, Berlin
ready
in the name: "var" → "variable"
It's fine to mount /var/ from tmpfs if you have a stateless system,
but writable it must be, otherwise your system is not compatible with
systemd and you get to keep the pieces.
Lennart
--
Lennart Poettering, Berlin
On Sa, 16.08.25 22:47, Demi Marie Obenour (demioben...@gmail.com) wrote:
> On a system where /etc is read-only, systemd-logind fails to start.
> I have tried making / a writable overlayfs without any success so
> far. The code is at https://github.com/DemiMarie/spectrum (branch
> b4/systemd) and
when this
> happens I usually choose to Ctrl-Alt-Del; grabbing the phone is slower
> than waiting it to reboot. Can I configure it give me some chances to
> retry?
Ask your distro to maybe backport
48cb1ad9c3fde47dc40b4345fa2efb2012596768 and related commits.
Lennart
--
Lennart Poettering, Berlin
-9.service
And then foobar.target would basically just consist of
WantedBy=multi-user.target in its [Install] section (and would be
shipped in /usr/, not generated by the generator). And you could
then hook the generated units into the boot via "systemctl enable
foobar.target".
But then again I really don't grok what you are trying to do, maybe I
misread your intentions entirely.
Lennart
--
Lennart Poettering, Berlin
t a tpm key, so so how can you
"start out" with a tpm key then? This doesn't compile in my head?
Lennart
--
Lennart Poettering, Berlin
side. It's really the tool of choice if you
want to augment disk images at first boot wit local keys that never
leave the host.
if you let systemd-repart do its thing you never have to enroll any
intermediary key or deal with volume keys or so, repart deals with
that and locks immediately and only to TPM.
Lennart
--
Lennart Poettering, Berlin
nk in general, but is
> there any documentation on how to enable specific systemd varlink endpoints?
No need to enable them. They are all enabled already, but it's all
recent stuff, and it doesn't cover everything the D-Bus APIs supported
so far.
Lennart
--
Lennart Poettering, Berlin
eir stuff
via the locking, too.
Lennart
--
Lennart Poettering, Berlin
almost 90 seconds to
> start.
You cannot really use the status output to determine that. Please look
at the proper logs, i.e. journalctl output, and please ideally even
turn on debug output, so you see in detail what is going
on. (i.e. systemd.log_level=debug) on the kernel cmdline.
Lennart
--
Lennart Poettering, Berlin
ly used.
>
> Yes, that is dangerous and should not be the default, I agree.
>
> 2. Silently ignoring user-requested list without any feedback whatsoever.
>
> I think that behavior is not acceptable. If you cannot satisfy user request,
> then do not pretend you succeeded. Let user
list
of PCRs that must strictly be included, but that should be used for
special cases only, never as default)
Lennart
--
Lennart Poettering, Berlin
On Fr, 09.05.25 09:31, Johannes Barthel
(johannes.bart...@farming-revolution.com) wrote:
> Hi,
>
> we're using an Ubuntu setup where systemd-coredump is set up as the coredump
> handler. This is fine, coredumps end up in /var/lib/systemd/coredump/. We
> would however like to additionally run ou
My educated guess is that this is a cgroupv1 vs. cgroupv2 issue. We do
not systematically test combinations of payload and host with
the two distinct apis, and there have been reports that things are
broken in that regard. And there's little interest to fix that,
because cgroupv1 is no longer supported by systemd anyway.
Lennart
--
Lennart Poettering, Berlin
On Mi, 07.05.25 09:07, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> > Maybe in your case, in the general case that's not so however. People
> > often dd images to disks, and hence it's essential the partitions show
> > up once tha
On Di, 06.05.25 13:03, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> > Not quite. it will issue that when a process closes the block device
> > after it was open for *write*. That's a relevant
> > distinction. Typically, userspace tool
)ed once, not 100 times.
Hence, your support line is wrong.
Lennart
--
Lennart Poettering, Berlin
On Di, 06.05.25 15:47, Lennart Poettering (lenn...@poettering.net) wrote:
> This is not new behaviour btw. It's widely documented (as above), and
> has been that way for decades.
(One more note: you can also disable the inotify thing if you like via
OPTIONS and "watch" i
our btw. It's widely documented (as above), and
has been that way for decades.
Lennart
--
Lennart Poettering, Berlin
imes you might still get a bad combination), but if clients are well
behaved this shouldn't matter (i.e., if a client first pins the
$CREDENTIALS_DIRECTORY dir by fd, and then opens the creds via
openat() from there, we get a consistent, atomic view of things).
Anyway, long story short: happy to review a patch for that.
Lennart
--
Lennart Poettering, Berlin
dr".
Other tools that manage variable like that are usually networking and
routing daemons. (Not systemd-networkd though, it doesn#t manager that one).
Lennart
--
Lennart Poettering, Berlin
a bit more information in its question, to
make this easier to grok.
Lennart
--
Lennart Poettering, Berlin
, I'd like to check if anyone still uses
that. And if you do: why?
Lennart
--
Lennart Poettering, Berlin
ither.
We already have PE parsers in our EFI code, we use it to find the UKI
sections after all, hence this wouldn't even add completely new PE
logic to our tree. It would just have to do the section relocation,
and then jump to the PE entrypoint of the inner image.
Would love a patch for that!
Lennart
--
Lennart Poettering, Berlin
to me?
it's fine if shim and sd-stub is used together, but the coupling
should be as loose as possible, since it's not clear at all to me that
shim should be part of clean boot stack.
I understand you have some attachment to shim. I don't understand
why. But let's not let that leak into our codebase.
Lennart
--
Lennart Poettering, Berlin
the ownership of the root inode? i.e. actually fix
the original problem that causes the message to show?
Lennart
--
Lennart Poettering, Berlin
just add this as local helper.
Also, this should be conditioned on the fstype (i.e. p->format), not
the partition type uuid, since it really applies to all fat
partitions, not just esps. (xbootldr for example needs the same).
Lennart
--
Lennart Poettering, Berlin
cular as some of the most popular distros never bothered with
Microsoft signed SB (notably ArchLinux).
But anyway, this is a different topic, let's not continue here.
Lennart
--
Lennart Poettering, Berlin
> a bit time pressing as both Plucky and Trixie are about to go out with
> this combination that used to work, but doesn't anymore.
> Without shim there's no new issue, everything works as it always did.
Maybe don't update shim then?
Lennart
--
Lennart Poettering, Berlin
ults in grub shedding code and removing a local
> reimplementation and using a common protocol instead, and sd-boot
> doing the exact opposite...
Urks. "NIH". Really? We have shipped a PE parser in sd-stub from day
one. It's pretty much what it does. If you think that's NIH and
terrible, then sd-stub isn't really an option for you.
Lennart
--
Lennart Poettering, Berlin
ons needed, and then jump into the entrypoint. It's simple,
it's fast, it's safe, works on any uefi implementation, improves
compatibility, adds no new deps on some niche protocol that binds us
to shim (which, I am so very sure is something we should support for
compat only at be
On Di, 11.03.25 13:27, Lennart Poettering (lenn...@poettering.net) wrote:
> On Mo, 10.03.25 19:25, Diorcet Yann (diorcet.y...@gmail.com) wrote:
>
> > Is PCR15 checked against a pre-calculated value saved in the signed initrd
> > before leaving initrd? If it's not the case,
ering the PCR state, then checking the
signature against the pinned SRK, and checking that the PCR
measurements we just made are actually in the logs.
Lennart
--
Lennart Poettering, Berlin
almost certainly triggered by WatchdogSec=. i.e. if services hang
for too long, we might restart them automatically to try to make
things better. This is of course ignorant of the question whether this
is a system wide hang or a specific hang on that service though.
See
https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#WatchdogSec=
for details.
Lennart
--
Lennart Poettering, Berlin
On Di, 11.03.25 13:16, Lennart Poettering (lenn...@poettering.net) wrote:
> On Mo, 10.03.25 12:27, Adrian Vovk (adrianv...@gmail.com) wrote:
>
> > Well, the TPM is supposed to be secure against hardware debugger access, in
> > theory. Ditto with CPUs, and JTAG lockout.
>
t.
Note that nothing of this is really a "bug" though, it's just an effect of
designing your trust model to be tighter or more relaxed.
Lennart
--
Lennart Poettering, Berlin
this is the same issue as the one you describe. Do you
> think that's correct?
>
> Lennart would have a better idea than I do of what mitigations to this
> would look like. But I suspect that:
>
> - You can't MITM the TPM, since the communication is encrypted
Nope. PCR measurements are not encrypted, at least not by systemd.
Lennart
--
Lennart Poettering, Berlin
ted + tpm). But if you have multiple partitions protected the
same way, why split them up, and why create such a headache then.
Lennart
--
Lennart Poettering, Berlin
ocked
> in normal situtation: as the first unlocked partition.
> If you don't add counter measure at the end of initrd in order to fail
> this trick (as alplanas explained), you will chroot on the malicious
> partition with the the good root partition unlocked and mounted as the
> second partition.
which counter measure do you precisely mean?
Lennart
--
Lennart Poettering, Berlin
eeds to be enabled manually,
it's only passphrase/recovery key unlock which is on by default, and
which you have to turn off via headless)
> - Make the update of the PCR due to the measuring of the malicious partition
> fails
hmm, i really cannot parse this? (not the rest either...?)
Lennart
--
Lennart Poettering, Berlin
has sat down implementing this.
TLDR: yes, we think doing this would be good, and we know how, but so
far noone did the work.
Sorry if that's disappointing.
Lennart
--
Lennart Poettering, Berlin
lication-memory-usage-with-systemd-kde-blogs/23804/11?u=piotr_dobrogost
> in the discussion pertaining to "Limit Application Memory Usage with
> systemd" blog post at
> https://blogs.kde.org/2024/10/18/limit-application-memory-usage-with-systemd/
Please file this as an issue in github (even better as a PR with your
suggested changes, and try to CC the right people from the two big
desktops.
Lennart
--
Lennart Poettering, Berlin
rd maintainers to make use of.
Lennart
--
Lennart Poettering, Berlin
systemd hater camp, because otherwise why would
you? but why in heaven do you then use it to start systemd after all?
your distro seems to have some split personality issues there)
And apparently they left the process running over the initrd→host
transition, inside the top-level cgroup (which causes it to be
migrated into the /init.scope cgroup by systemd early on), and be
considered a process auxiliary to PID 1.
Anyway, there's a lot wrong with your distro here, please contact
them. This doesn't appear to be an upstream systemd issue at all, …
Lennart
--
Lennart Poettering, Berlin
in the same way?
Well, it's not systemd that enqueues those restarts on its own. It's
some D-Bus client. use "busctl monitor" to figure out what that might
be.
you probably have some script or other service thta issues "systemctl
restart" on the service. figure out which one that is.
Lennart
--
Lennart Poettering, Berlin
s its "leader" and binds the session's
lifetime to that leader process lifetime. Except of course you are
using some distro that turns KillUserProcesses= off, which disables
this logic for compat with legacy.
Lennart
--
Lennart Poettering, Berlin
at properly fscks
the rootfs before mounting it and you definitely know you want the
rootfs writable and mutable (i.e. your OS doesn't support immutable
operation), then just drop "ro" from the kernel cmdline together,
there's really no point in first mounting it read-only just to
ename to ensure
that the tools always use the library built from basically the same
sources.
hence, what you are trying to do is expressly against what this
library is.
Lennart
--
Lennart Poettering, Berlin
ets a SIGHUP because of that.
>
> Brian M also suggested that might be the cause, but I don't see any
> ttys when I do "ls -l /proc//fd".
it's not so much about that, but about which ctty your process has.
Lennart
--
Lennart Poettering, Berlin
idea, there's not
sane authentication let alone encryption. It's not built for
that.
If you want remoting, then connect to a remote bus via ssh, systemd's
sd-bus makes that reasonably easy. See sd_bus_open_system_remote().
But please, don't do unencrypted D-Bus remotely.
xLennart
--
Lennart Poettering, Berlin
HUP to the child?
Are you sure you are setting argv[0][0] properly? the killing spree we
do on switch root should exclude processes marked like that.
Note that we'll also possibly reinitialize the tty on switch root,
maybe your tool has the tty open and gets a SIGHUP because of that.
Lennart
--
Lennart Poettering, Berlin
you have your culprit.
Lennart
--
Lennart Poettering, Berlin
undamental units of systemd:
> LoadError=org.freedesktop.systemd1.UnitMasked "Unit cryptsetup.target
> is masked."
This disables key synchronization points, and the things just fail.
Lennart
--
Lennart Poettering, Berlin
%N, %o, %p, %u, %U, %v, %w, %W, %%"
>
> But I think some are valid in (some) directives of the [Unit] or [Service]
> section.
>
> My use case would be to express a dynamic activation and order dependency on
> a device name known only at boot time.
Please provide a minimal example of a unit file you think should work
but doesn't.
Lennart
--
Lennart Poettering, Berlin
think you can invest a bit of time every now and
then to maintain the tool in the future I'd be happy to pass over
maintainership to you, if you are interested?
Lennart
--
Lennart Poettering, Berlin
than
/var/lib/crash?
If you use the latter you can use StateDirectory=crash instead.
> /proc/vmcore "/var/crash/crashdump-$$(date +%%F-%%T)"'
> ExecStartPost=reboot
Note that "reboot" is actually a sysv legacy command. The most elegant
way to reboot after the service is complete is via
SuccessAction=reboot in the [Unit] section. See systemd.unit(5) man
page for more info.
Lennart
--
Lennart Poettering, Berlin
doesn't sound like a systemd issue, but like maybe some kind of
configuration management tool's work? Are you running something like
that? please contact your OS vendor for help.
Lennart
--
Lennart Poettering, Berlin
ou use very old versions, then please ask the
maintainer of that old version for help, not us upstream.
Lennart
--
Lennart Poettering, Berlin
approach impact
> portable services in systemd? Could it cause any issues with how
> portable service images are accessed or made visible, especially if
> they depend on shared mount propagation?
Lennart
--
Lennart Poettering, Berlin
se this functionality via Varlink too, so that you can just do a
method call to get a list of all local Varlink sockets, from where you
could then go on.
Lennart
--
Lennart Poettering, Berlin
th it because it forces so many roundtrips and a
single data pipe through the broker process. Roundtrips kill your
performance, JSON marshalling is entirely irrelevant for that.
People have done profiling on this. For example zbus' Zeeshan Ali
posted about this on Mastodon some time ago, where
ce units actually
*does* suppport MOVE_MOUNT_BENEATH already, it's only the system-wide
concept that doesn't. And we really should change that.)
Lennart
--
Lennart Poettering, Berlin
quite problematic I would say. What's the
rationale for that?
Note that systemd sends SIGABRT for various reasons on its own, for
example in context of the per-service watchdog logic. Hence,
redefining locally what it means substantially changes the contract
between services and the service manager.
Lennart
--
Lennart Poettering, Berlin
is not available yet, and read-only. hence, it's almost
certainly *wrong* to allow applications to see the real-one: they
should not expect they can write there, and its a terrible place to
read information from (since it's an unmanaged shared namespace).
Hence, you probably will have a ve
(logind will re-retrigger relevant devices whenever the fg
session changes, so that the udev rules are rerun and apps are
notified about the new situation via udev events)
Lennart
--
Lennart Poettering, Berlin
ntry to ^WHATEVER\+\d+(-\d+)?.conf$ ?
See loader.conf(5). It supports globs, it's literally in the first
sentence. (i.e. * and ?)
That said, i think we actually should check the glob against the
string where we stripped away the counters. Could you file a bug
against that?
Lennart
--
Lennart Poettering, Berlin
reply.
>
> Is my second statement also correct?
>
> i.e. is there no way to prevent mounting a private /tmp when executing
> generators using something like an environment variable or config setting?
There is none.
Lennart
--
Lennart Poettering, Berlin
cally can use sd_varlink_server_loop_auto() as blue print
for this, but you drop the exit on idle stuff, and instead of the
sd_event_loop() at the end you do what the sd_event_get_fd() man page
explains.
Lennart
--
Lennart Poettering, Berlin
On Di, 19.11.24 01:45, Nils Kattenbeck (nilskem...@gmail.com) wrote:
> On Tue, Nov 19, 2024 at 1:00 AM Lennart Poettering
> wrote:
> >
> > On Do, 14.11.24 14:25, Phillip Susi (ph...@thesusis.net) wrote:
> >
> > > Lennart Poettering writes:
> > >
> &g
nce generators do not have access to the system's /tmp/
and get a transient one.
Lennart
--
Lennart Poettering, Berlin
On Do, 14.11.24 14:25, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> > the BLKFLSBUF ioctl() works fine on block device fds open for read only.
>
> Oh, I might have to change that to use a read only open then.
>
> > I am not following a
have a useful checksum
covering enough relevant data, and it can never really catch scenarios
where a disk is comprehensively repartitioned, i.e. one or more fs and
partition metadata changed at the same time...
Lennart
--
Lennart Poettering, Berlin
On Mo, 11.11.24 08:34, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> >> I'm reading between the lines a bit, but my guess is that libparted
> >> always opens the device writable in case you start issuing actual
> >> partitionin
On Do, 31.10.24 12:08, Dan Nicholson (d...@endlessos.org) wrote:
> On Thu, Oct 31, 2024 at 10:23 AM Lennart Poettering
> wrote:
> >
> > On Do, 31.10.24 09:03, Phillip Susi (ph...@thesusis.net) wrote:
> >
> > > Lennart Poettering writes:
> > >
>
On Do, 31.10.24 09:03, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> > Doing the locking on the fd you use for writing makes things a lot
> > easier, because as mentioned udev will automatically retrigger block
> > devices if an inotify
ll have running processes, sorry. And
I am pretty sure we should not support this.
I'd recommend figuring out why these processes do not react to SIGKILL
instead of hiding the issue.
Lennart
--
Lennart Poettering, Berlin
#x27;s Tomcat.
Lennart
--
Lennart Poettering, Berlin
On Di, 29.10.24 08:28, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> > It prevents it fully. However, udev installs an inotify watch on all
> > relevant block devices, which watches for IN_CLOSE_WRITE events, and
> > then triggers the device
> start a session, but not close it.
>
> How can I get these 2 processes to shutdown?
They are part of the per-user service manager we are maintaining. They
go away once the user fully logged out, after a brief time-out (which
can be controlled via UserStopDelaySec= (only since v240).
Lennart
--
Lennart Poettering, Berlin
On Do, 24.10.24 15:43, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> > systemd is downstream to udev. If udev doesn't process a block device
> > because of the taken BSD file lock on the main block device, then
> > systemd (and other d
n the Linux kernel command line, that
> is passed to systemd/the OS somehow?
There's systemd.clock-usec=. See kernel-command-line(7) man page for details.
Lennart
--
Lennart Poettering, Berlin
u think of any other way to prevent this unwanted auto mounting
> besides masking the mount units?
systemd is downstream to udev. If udev doesn't process a block device
because of the taken BSD file lock on the main block device, then
systemd (and other downstreams of udev) won't g
hat this seems not perfect
> either.
I don#t follow? What do you mean by "systemd --user" is not
"-/bin/bash"?
Lennart
--
Lennart Poettering, Berlin
t it does, you
are *asking* for the rootfs to be replaced by a minimal tmpfs.
Lennart
--
Lennart Poettering, Berlin
use the assumption that reloads happen
under service control and that processes survive and the execution
contetx is not reset. It's explicitly supported to change the main PID
of the service (for example via sd_notify("MAINPID=")) during reloads
even, hence this should cover things reasonably nice for you.
Lennart
--
Lennart Poettering, Berlin
> line parameter at run time with the latest SHA deployment.
You can use systemd credentials for that, but would have to tell
ostree to look in one for that. systemd credentials can be locked
against the local TPM, and hence be authenticated that way.
Lennart
--
Lennart Poettering, Berlin
fi.extra.d/waldo.addon.efi
i.e. the ….extra.d/ subdir is where to place things.
Also make sure your systemd-stub is new enough. i.e. at least v254,
better newer.
Lennart
--
Lennart Poettering, Berlin
you need to do:
https://github.com/systemd/systemd/blob/main/man/ukify.xml#L674
Lennart
--
Lennart Poettering, Berlin
y code
(i.e. no real PE stub, and no .linux section). They can be
SecureBoot signed like any other PE binary, which is how they are
authenticated. You can drop them as "side-car" next to your UKI and
their contents will be combined/override the relevant sections in
the main UKI. This is already available in released systemd
versions. See sd-stub man page for details.
Lennart
--
Lennart Poettering, Berlin
On Fr, 04.10.24 15:03, Fredrik Hugosson (h...@axis.com) wrote:
> On 2024-09-11 14:28, Lennart Poettering wrote:
> > On Mi, 11.09.24 11:43, Fredrik Hugosson (fredrik.hugos...@axis.com) wrote:
> >
> > > Hi!
> > >
> > > I'm trying to use the
&
r memory is never paged out,
then mlockal() or something similar is the way to go. But of course
you need ot know what you are doing, and verify that locking your code
into memory won't cause memory pressure on other processes where you'd
rather not have it.
Lennart
--
Lennart Poettering, Berlin
hing I'd suggest people to avoid, and if they do it
anyway, then at least only for a short time (i.e. terminate once boot
is complete or so)
Lennart
--
Lennart Poettering, Berlin
gt; IIRC normally none of the initramfs services are expected to survive the
> transition.
Yes, that's the recommendation.
Lennart
--
Lennart Poettering, Berlin
1 - 100 of 1106 matches
Mail list logo
