Can do revert commit a432668 ?

I just brought back the build option because it may be useful on other distros. The rest... I don't see why you would use it on NixOS, given with the service running unprivileged. Am I missing something?

I thought it was possible to make a default parameter. I use profile hardened and jemalloc memory allocator. The default profile uses the scudo memory allocator, which dhcpcd also works with.

I thought it was possible to make a default parameter.

I'm not sure what you mean: enablePrivSep ? true? IIRC it can't be disabled at runtime, so dhcpcd alway tries to setuid and crashes because it's now running as an unprivilged user.

What if you try deleting those lines?
https://github.com/NetworkConfiguration/dhcpcd/blob/58230c23e2e4e1c694968f6a09d8cab46ecf9c7a/src/privsep.c#L137-L140

But what for? Privsep is now unnecessary thanks to the systemd hardening, and if for some reason you want a different configuration you can just do dhcpcd.override { enablePrivSep = true; }.

But what for? Privsep is now unnecessary thanks to the systemd hardening, and if for some reason you want a different configuration you can just do dhcpcd.override { enablePrivSep = true; }.

Ok.

Have you tried comparing capabilites between the two options at the dhcpcd processes?

Capabilites with use enablePrivSep:

CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 00000000000434c0
CapAmb: 0000000000000000

0x00000000000434c0=cap_setgid,cap_setuid,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_chroot

Capabilites without use enablePrivSep and run as unprivileged user:

CapInh: 0000000000203500
CapPrm: 0000000000003400
CapEff: 0000000000003400
CapBnd: 000001f3f5fcffff
CapAmb: 0000000000003400

0x0000000000203500=cap_setpcap,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_admin
0x0000000000003400=cap_net_bind_service,cap_net_admin,cap_net_raw
0x000001f3f5fcffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_tty_config,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

Capabilites with use enablePrivSep and run as unprivileged user:

CapInh: 0000000000043440
CapPrm: 0000000000043440
CapEff: 0000000000043440
CapBnd: 000001ffffffffff
CapAmb: 0000000000043440

0x0000000000043440=cap_setgid,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_chroot

Edit: Updated the test results.

I'm not sure what you're getting at, I don't see anything unexpected: systemd sets the ambient capabilities to "CAP_NET_ADMIN, CAP_NET_RAW CAP_NET_BIND_SERVICE", then inheritable = permitted = effective = ambient and everything is in the bouding set.

I've updated the previous comment.
Judging by the tests the parameter using the enablePrivSep parameter, the service needs to be granted more privileges.
I thought it would be the other way around.

I assume there is no point to this parameter then?

You mean building dhcpcd with enablePrivSep = true? As I said earlier, it may be useful on other distros without systemd (hardening).

You mean building dhcpcd with enablePrivSep = true?

Yes, also had to add a few parameters to AmbientCapabilities as well.

As I said earlier, it may be useful on other distros without systemd (hardening).

Ok.