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
+++ b/src/shared
---
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 recursive_relabel_chi
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
ind
---
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 jour
---
src/delta/delta.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/delta/delta.c b/src/delta/delta.c
index 0785e7b..dcf25d1 100644
--- a/src/delta/delta.c
+++ b/src/delta/delta.c
@@ -280,13 +280,12 @@ static int enumerate_dir(Hashmap *top, Hashmap *bottom,
Hashma
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 b/src/share
---
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, c
---
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 readdir_r
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
--- a/src/journal
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
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.
aches, which are much, much larger.
Note that in this particularly, I'm not concerned about cache poisoning
through spoofing, but due to algorithm bugs. And for explaining those
bugs, cache dumps help as well.
--
Florian Weimer / Red Hat Product Security
Even
if you follow CNAME chains, 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@
Start=@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
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 setti
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
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 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 5
tening
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 / R
ecause that doesn't
look very 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 gen
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 gen
Ah, so it builds down to our distrust of hardware 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 rema
is for specific 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 m
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
, 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 Sec
* 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(&err);
> + } while(pid == -1 && errno != -ECHILD);
> +
> + if (WIFSIGNALED(err))
> +
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
sy
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/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 users to the
service.
No they don't. Basic Fedora works fine in this mode, without any
changes. It isn#t round, and it isn'
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 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 fea
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
* 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 n
* 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 reall
* 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 change
* 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, I backported t
* 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, I backported t
* 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:
> 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:
>> >>
>
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 mailin
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
___
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 <+7
* 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 on
* 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 al
* 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 th
* 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 mp
* 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
55 matches
Mail list logo
