socket for SSH, but block the actual service startup until the keys have
been generated after sufficient entropy became available?
What would you need on the kernel side to implement the waiting?
(Textual comparison of a log message is only good for a prototype.)
--
Florian Weimer / Red Hat
backwards-compatible to me.
--
Florian Weimer / Red Hat Product Security Team
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On 04/30/2014 01:08 PM, Lennart Poettering wrote:
On Tue, 29.04.14 20:43, Florian Weimer (fwei...@redhat.com) wrote:
The message at
https://mail.gnome.org/archives/ostree-list/2014-February/msg00010.html
contains two boot traces from virtual machines which show that the
SSH key is generated
On 04/30/2014 01:14 PM, Daniel P. Berrange wrote:
On Tue, Apr 29, 2014 at 08:43:38PM +0200, Florian Weimer wrote:
The message at
https://mail.gnome.org/archives/ostree-list/2014-February/msg00010.html
contains two boot traces from virtual machines which show that the
SSH key is generated
RNGs? How annoying.
We should be able to trust Fedora-on-Fedora (or Debian-on-Debian or
whatever) scenarios. But I get that in the general case, it's
impossible to know what's on the other side of the virtio_rng side, so
reservations remain.
--
Florian Weimer / Red Hat Product Security Team
services only. For things like hash tables,
it's possible to reseed once more randomness becomes available, but
that's not true for long-term key generation.
--
Florian Weimer / Red Hat Product Security Team
___
systemd-devel mailing list
systemd-devel
On 05/05/2014 04:35 PM, Lennart Poettering wrote:
On Wed, 30.04.14 17:06, Florian Weimer (fwei...@redhat.com) wrote:
On 04/30/2014 02:28 PM, Daniel P. Berrange wrote:
Interesting suggestion. I just used virt-manager to create the VM.
I don't see any trace for rng or random in the domain
This patch series removes all uses of readdir_r. The changes are not
entirely mechanical, some of the patches fix bugs in error handling.
readdir_r is rather broken on Linux because there are some directories
it cannot read.
Florian Weimer (11):
tmpfiles: replace readdir_r with readdir
---
src/login/sd-login.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/login/sd-login.c b/src/login/sd-login.c
index c9a2e8a..2930b87 100644
--- a/src/login/sd-login.c
+++ b/src/login/sd-login.c
@@ -555,13 +555,13 @@ _public_ int sd_get_uids(uid_t **users) {
The old code incorrectly assumed that readdir_r updates errno.
---
src/shared/install.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/src/shared/install.c b/src/shared/install.c
index 17e8a75..5001ad4 100644
--- a/src/shared/install.c
+++
---
src/tmpfiles/tmpfiles.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index b7f6a2e..e83a73e 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -543,15 +543,15 @@ static int
The available_space function now returns 0 if reading the directory
fails. Previously, such errors were silently ignored.
---
src/journal/journald-server.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
---
src/journal/journal-vacuum.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/journal/journal-vacuum.c b/src/journal/journal-vacuum.c
index d4a1c6c..b2b47d6 100644
--- a/src/journal/journal-vacuum.c
+++ b/src/journal/journal-vacuum.c
@@ -180,9 +180,7 @@ int
This fixes rm_rf_children_dangerous to detect errors during directory
reading. Previously, it could dereference an uninitialized pointer.
---
src/shared/util.c | 37 +
1 file changed, 17 insertions(+), 20 deletions(-)
diff --git a/src/shared/util.c
---
src/core/load-dropin.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/core/load-dropin.c b/src/core/load-dropin.c
index a877e66..3504009 100644
--- a/src/core/load-dropin.c
+++ b/src/core/load-dropin.c
@@ -63,12 +63,13 @@ static int iterate_dir(
for
---
src/shared/conf-files.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/shared/conf-files.c b/src/shared/conf-files.c
index 92204a6..c86bb03 100644
--- a/src/shared/conf-files.c
+++ b/src/shared/conf-files.c
@@ -53,13 +53,13 @@ static int files_add(Hashmap *h,
---
TODO | 1 -
src/shared/util.h | 6 --
2 files changed, 7 deletions(-)
diff --git a/TODO b/TODO
index 2e3becc..1e8f2b0 100644
--- a/TODO
+++ b/TODO
@@ -48,7 +48,6 @@ Features:
- ensure scope units may be started only a single time
* code cleanup
- - get rid of
This commit also adds error handling for failures during
directory reading.
---
src/journal/sd-journal.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/src/journal/sd-journal.c b/src/journal/sd-journal.c
index bb116df..283d593 100644
---
On 12/20/2013 08:50 PM, Colin Walters wrote:
On Thu, 2013-12-19 at 14:20 +0100, Florian Weimer wrote:
readdir_r is rather broken on Linux because there are some directories
it cannot read.
Citation? Are you talking about
http://womble.decadent.org.uk/readdir_r-advisory.html
?
Partly, yes
.
Interesting. Will there be an alternative for I/O bandwidth throttling?
--
Florian Weimer / Red Hat Product Security Team
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
, and so
on. For example, bus_kernel_make_starter is called after forking and
does a lot of things.
But the real question is what you would need to get rid of the
syscall(__NR_clone) in src/nspawn/nspawn.c.
--
Florian Weimer / Red Hat Product Security
Is there some documentation of the D-Bus API and its expected behavior?
And is there a way to dump the contents of the internal cache?
--
Florian Weimer / Red Hat Product Security
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
On 10/20/2014 09:36 PM, Lennart Poettering wrote:
On Tue, 14.10.14 11:54, Florian Weimer (fwei...@redhat.com) wrote:
Is there some documentation of the D-Bus API and its expected
behavior?
No. We have not documented this so far, as we don't want to guarantee
API stabilitiy for this yet
, you should only the initial name (QNAME) as
a cache lookup key, adding the entire CNAME chain still can lead to
cache poisoning.
--
Florian Weimer / Red Hat Product Security
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http
=@rootlibexecdir@/systemd-localed
BusName=org.freedesktop.locale1
CapabilityBoundingSet=
…
What's the intent of these settings? Is it a form of hardening? If
yes, it is rather ineffective because UID=0 does not need any
capabilities to completely compromise the system.
--
Florian Weimer / Red Hat
On 07/20/2015 01:52 PM, Reindl Harald wrote:
Am 20.07.2015 um 13:24 schrieb Florian Weimer:
CapabilityBoundingSet=CAP_IPC_OWNER CAP_SETUID CAP_SETGID CAP_SETPCAP
m4_ifdef(`HAVE_SMACK', CAP_MAC_ADMIN )
…
What's the intent of these settings? Is it a form of hardening? If
yes
On 07/20/2015 02:34 PM, Reindl Harald wrote:
Am 20.07.2015 um 13:58 schrieb Florian Weimer:
On 07/20/2015 01:52 PM, Reindl Harald wrote:
Am 20.07.2015 um 13:24 schrieb Florian Weimer:
CapabilityBoundingSet=CAP_IPC_OWNER CAP_SETUID CAP_SETGID CAP_SETPCAP
m4_ifdef(`HAVE_SMACK
the service, they can impersonate it by binding to the same port.
Does socket activation reliably prevent such impersonation attacks? Or
is there race, say during systemd configuration reloading or service
restarts, where systemd temporarily does not listen to that port?
--
Florian Weimer / Red Hat
On 07/21/2015 01:52 PM, David Herrmann wrote:
Hi
On Tue, Jul 21, 2015 at 1:37 PM, Florian Weimer fwei...@redhat.com wrote:
We have quite a zoo of services which listen on localhost, on a fixed
TCP port, for use by local clients. The canonical example is PostgreSQL
on 5432/TCP
* Steve Dickson:
> +static void
> +sig_child(int signal)
> +{
> + int err;
> + pid_t pid;
> +
> + /* Parent: just wait on child to exit and return */
> + do {
> + pid = wait();
> + } while(pid == -1 && errno != -ECHILD);
> +
> + if (WIFSIGNALED(err))
> +
On 05/20/2016 02:59 PM, Lennart Poettering wrote:
On Fri, 20.05.16 14:01, Florian Weimer (fwei...@redhat.com) wrote:
The default systemd configuration runs ldconfig at boot. Why?
It's conditionalized via ConditionNeedsUpdate=, which means it is only
run when /etc is older than /usr
On 05/20/2016 04:04 PM, Lennart Poettering wrote:
On Fri, 20.05.16 15:55, Florian Weimer (fwei...@redhat.com) wrote:
On 05/20/2016 02:59 PM, Lennart Poettering wrote:
On Fri, 20.05.16 14:01, Florian Weimer (fwei...@redhat.com) wrote:
The default systemd configuration runs ldconfig at boot
On 05/23/2016 11:59 AM, Lennart Poettering wrote:
On Mon, 23.05.16 11:34, Florian Weimer (fwei...@redhat.com) wrote:
On 05/20/2016 04:10 PM, Lennart Poettering wrote:
If such systems require specialized unit files, then you can put
ldconfig.service there, instead of exposing all systemd
The default systemd configuration runs ldconfig at boot. Why?
Most deployments of systemd appear to be dynamically linked, so if the
ld.so caches are corrupted, you will never get to the point where you
can run ldconfig.
Running ldconfig too early tends to cause problems because the file
The manual page I've got does not say it is, but the implementation does
not wait for acknowledgment from the journal. The implementation does
not block explicitly, but I think the sendmsg call can block until the
receiver queue is empty.
The background for this question is that we have a
On 02/06/2017 12:36 PM, Lennart Poettering wrote:
On Mon, 06.02.17 11:12, Florian Weimer (fwei...@redhat.com) wrote:
The manual page I've got does not say it is, but the implementation does not
wait for acknowledgment from the journal. The implementation does not block
explicitly, but I think
* Lennart Poettering:
> On Tue, 11.07.17 21:26, Florian Weimer (f...@deneb.enyo.de) wrote:
>
>> * Lennart Poettering:
>>
>> > Apparently, this regressed between this version and
>> > glibc-2.24-9.fc25.x86_64 hence.
>>
>> Yes,
* Lennart Poettering:
> On Tue, 11.07.17 21:24, Florian Weimer (f...@deneb.enyo.de) wrote:
>
>> * Lennart Poettering:
>>
>> > This all stems from my experiences with PulseAudio back in the day:
>> > People do not grok the effect of fork(): it only duplicat
* Lennart Poettering:
> On Tue, 11.07.17 21:26, Florian Weimer (f...@deneb.enyo.de) wrote:
>
>> * Lennart Poettering:
>>
>> > Apparently, this regressed between this version and
>> > glibc-2.24-9.fc25.x86_64 hence.
>>
>> Yes,
* Lennart Poettering:
> On Wed, 12.07.17 09:53, Florian Weimer (f...@deneb.enyo.de) wrote:
>
>> * Lennart Poettering:
>>
>> > On Tue, 11.07.17 21:24, Florian Weimer (f...@deneb.enyo.de) wrote:
>> >
>> >> * Lennart Poettering:
>> >>
>
* Lennart Poettering:
> On Wed, 12.07.17 09:51, Florian Weimer (f...@deneb.enyo.de) wrote:
>
>> * Lennart Poettering:
>>
>> > On Tue, 11.07.17 21:26, Florian Weimer (f...@deneb.enyo.de) wrote:
>> >
>> >> * Lennart Poettering:
>> >&
* Lennart Poettering:
> This all stems from my experiences with PulseAudio back in the day:
> People do not grok the effect of fork(): it only duplicates the
> invoking thread, not any other threads of the process, moreover all
> data structures are copied as they are, and that's a time bomb
* Lennart Poettering:
> Apparently, this regressed between this version and
> glibc-2.24-9.fc25.x86_64 hence.
Yes, I backported the fork cache removal to Fedora 25. There is no
longer a good way to main such a cache in userspace because glibc
cannot intercept anymore all the ways that can
* Michael Chapman:
> It's a pity glibc doesn't provide an equivalent for pthread_atfork()
> outside of the pthread library. Having a notification that a fork has just
> occurred would allow us to do the PID caching ourselves.
In fact, it does, as a public symbol: __register_atfork.
It's just
On 05/16/2018 11:52 PM, Lennart Poettering wrote:
Hence, please go aahead and drop it from the rpm scripts.
Thanks for the clear advice. I filed
https://bugzilla.redhat.com/show_bug.cgi?id=1579225
to track the removal.
Florian
___
In Fedora, for historic reasons, we run “/sbin/telinit u” after
installing a new glibc RPM package version.
Does this still make sense? Should we remove the code which invokes
telinit from the glibc package?
Thanks,
Florian
___
systemd-devel
* tedheadster:
> Here is the full disassembly with a few comments:
>
> (gdb) disassemble
> Dump of assembler code for function rdrand:
>0xb7e21440 <+0>: push %esi
>0xb7e21441 <+1>: push %ebx
>0xb7e21442 <+2>: call 0xb7e0af5d <__x86.get_pc_thunk.si>
>0xb7e21447
* Topi Miettinen:
>> The dynamic loader has to process the LOAD segments to get to the ELF
>> note that says to enable BTI. Maybe we could do a first pass and
>> load only the segments that cover notes. But that requires lots of
>> changes to generic code in the loader.
>
> What if the loader
* Lennart Poettering:
> On Mi, 21.10.20 22:44, Jeremy Linton (jeremy.lin...@arm.com) wrote:
>
>> Hi,
>>
>> There is a problem with glibc+systemd on BTI enabled systems. Systemd
>> has a service flag "MemoryDenyWriteExecute" which uses seccomp to deny
>> PROT_EXEC changes. Glibc enables BTI only
* Topi Miettinen:
> Allowing mprotect(PROT_EXEC|PROT_BTI) would mean that all you need to
> circumvent MDWX is to add PROT_BTI flag. I'd suggest getting the flags
> right at mmap() time or failing that, reverting the PROT_BTI for
> legacy programs later.
>
> Could the kernel tell the loader of
* Dave Martin via Libc-alpha:
> On Mon, Oct 26, 2020 at 05:45:42PM +0100, Florian Weimer via Libc-alpha wrote:
>> * Dave Martin via Libc-alpha:
>>
>> > Would it now help to add something like:
>> >
>> > int mchangeprot(void *addr, size_t len, int old_fl
* Dave Martin via Libc-alpha:
> Would it now help to add something like:
>
> int mchangeprot(void *addr, size_t len, int old_flags, int new_flags)
> {
> int ret = -EINVAL;
> mmap_write_lock(current->mm);
> if (all vmas in [addr .. addr + len) have
> their
52 matches
Mail list logo
