On Tue, 3 Jan 2023 01:48:29 +0100 Adam Borowski wrote:
Most settings are in /etc/sysctl.conf, especially network related ones.
Package provided default values should be shipped in /usr, local
overrides should go to /etc
That /usr/lib/sysctl.d/ path doesn't have its settings applied normal
On Sat, 2023-01-07 at 16:55 -0800, Steve Langasek wrote:
> On Tue, Jan 03, 2023 at 03:26:37AM +0100, Marco d'Itri wrote:
>
> > Nowadays systemd is a source of common sysctl settings among different
> > distributions.
>
> Debian still supports other init systems in the archive besides systemd.
On Tue, Jan 03, 2023 at 03:26:37AM +0100, Marco d'Itri wrote:
> On Jan 03, Adam Borowski wrote:
> > Debian's default sysctl settings should reside in procps (as it owns
> > /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> > package.
> Nowadays systemd is a source of common sys
On Tue, Jan 03, 2023 at 03:26:37AM +0100, Marco d'Itri wrote:
> > Debian's default sysctl settings should reside in procps (as it owns
> > /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> > package.
> Nowadays systemd is a source of common sysctl settings among different
> dist
On Jan 03, Adam Borowski wrote:
> Debian's default sysctl settings should reside in procps (as it owns
> /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> package.
Nowadays systemd is a source of common sysctl settings among different
distributions.
--
ciao,
Marco
signatur
On Tue, Jan 03, 2023 at 01:48:29AM +0100, Adam Borowski wrote:
> Most settings are in /etc/sysctl.conf, especially network related ones.
>
> That /usr/lib/sysctl.d/ path doesn't have its settings applied normally.
systemd-sysctl is run by default and processes /usr/lib/sysctl.d/. This
is the cas
On Mon, Jan 02, 2023 at 04:43:34PM -0800, Noah Meyerhans wrote:
> > Debian's default sysctl settings should reside in procps (as it owns
> > /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> > package.
>
> Is that documented anywhere? It's certainly not the case today:
>
> $ f
On Tue, Jan 03, 2023 at 01:36:30AM +0100, Adam Borowski wrote:
> > > I'm entirely happy to reassign this request to systemd and have the
> > > setting applied more broadly.
> > Some options:
> > - conflict with systemd < version_with_the_new_default
> > - wait for a full release and then just drop
On Tue, Jan 03, 2023 at 12:43:31AM +0100, Marco d'Itri wrote:
> On Jan 02, Noah Meyerhans wrote:
> > I'm entirely happy to reassign this request to systemd and have the
> > setting applied more broadly.
> Some options:
> - conflict with systemd < version_with_the_new_default
> - wait for a full re
On Jan 02, Noah Meyerhans wrote:
> I'm entirely happy to reassign this request to systemd and have the
> setting applied more broadly. The question that arises then is what to
> do about the file-level capabilities on the ping binary. Ideally we
> drop them entirely (including the setuid fallba
On Mon, Jan 02, 2023 at 10:09:44PM +0100, Marco d'Itri wrote:
> > With that in place, unprivileged users are able to excute ping for both
> > IPv4 and IPv6 targets without cap_net_raw (currently set as either a
> > file-based attribute on the ping binary or acquired via setuid). But
> > since that
On Jan 02, Noah Meyerhans wrote:
> With that in place, unprivileged users are able to excute ping for both
> IPv4 and IPv6 targets without cap_net_raw (currently set as either a
> file-based attribute on the ping binary or acquired via setuid). But
> since that applies system-wide, not just to t
12 matches
Mail list logo
