On Apr 12, Helmut Grohne wrote:
> As much as I like unprivileged operation, I think this change may expand
> privileges beyond what we expect. At present, ping limits an
> unprivileged user to a minimum spacing of 2ms and prevents a flood ping.
> Of course a user can just run multiple ping proces
Hi,
On Mon, Jan 02, 2023 at 12:01:54PM -0800, Noah Meyerhans wrote:
> See bug #1008281 for context. [1]
>
> The proposal is to install /usr/lib/sysctl.d/iputils-ping.conf with the
> following content:
> net.ipv4.ping_group_range="0 2147483647"
>
> With that in place, unprivileged users are able
On Sun, Jan 15, 2023 at 02:35:06AM +0100, Ángel wrote:
> I would change that to:
Please don't. If we change the distribution default for
net.ipv4.ping_group_range, then ping should refrain from ever trying to
check for it and never make the executable privileged.
Bastian
--
There is a multi-le
On 2023-01-02 at 13:55 -0800, 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 (includin
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 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 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 Mon, Jan 02, 2023 at 10:11:38PM +0100, Marco d'Itri wrote:
> On Jan 02, Peter Pentchev wrote:
>
> > I personally would prefer giving the administrator a way to change that.
> > Maybe add a low priority debconf question with a "ping is not setuid"
> > default, then mention that debconf setting
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
On Jan 02, Peter Pentchev wrote:
> I personally would prefer giving the administrator a way to change that.
> Maybe add a low priority debconf question with a "ping is not setuid"
> default, then mention that debconf setting in a comment in the file that
> the package installs in the sysctl.d/ di
On Mon, Jan 02, 2023 at 12:01:54PM -0800, Noah Meyerhans wrote:
> There are several examples of packages installing files to
> /usr/lib/sysctl.d, but I haven't found any specific guidance on policies
> about what's appropriate for them. Since sysctl variables change the
> system behavior in a way
There are several examples of packages installing files to
/usr/lib/sysctl.d, but I haven't found any specific guidance on policies
about what's appropriate for them. Since sysctl variables change the
system behavior in a way that's not limited to the package changing the
setting, and since the pa
15 matches
Mail list logo
