l2ping(8) and -f switch
Alexander Best
arundel at freebsd.org
Mon Mar 28 19:59:52 UTC 2011
On Mon Mar 28 11, Maksim Yevmenkin wrote:
> On Mon, Mar 28, 2011 at 7:04 AM, Iain Hibbert <plunky at rya-online.net> wrote:
> > On Mon, 28 Mar 2011, Alexander Best wrote:
> >
> >> On Mon Mar 28 11, Iain Hibbert wrote:
> >> > On Mon, 28 Mar 2011, Alexander Best wrote:
> >> >
> >> > > thus i believe making the -f switch only accessable to super-users (in
> >> > > accordance with ping(8)/ping6(8)) would increase security.
> >> >
> >> > what stops the user from recompiling l2ping without this restriction?
> >>
> >> nothing. but what stops him from recompiling ping(8) or ping6(8) without the
> >> restriction? still it's there.
> >
> > AFAIK you need superuser privileges to even send ICMP_ECHO packets, thats
> > why ping is traditionally a suid program and making a new binary won't
> > help normal users.. I'm guessing that l2ping doesn't have the same
> > restrictions?
>
> Guys,
>
> first of all thanks for the patch.
>
> i think one really needs to understand what "flood" really means in
> l2ping(8). "flood" ping(8) basically floods the link with icmp echo
> requests without waiting for remote system to reply. yes, this is
> potentially dangerous and thus its reasonable to require super-user
> privileges. "flood" l2ping(8) is NOT the same. all l2ping(8) does is
> "flood" mode
>
> 1) sends l2cap echo request
> 2) waits for l2cap echo response (or timeout)
> 3) repeats
>
> in other words, there is no delay between each l2cap echo
> request-response transaction. its not really "flood". i'm not sure if
> it really worth to go all the way to restricting this. however, if
> people think that it should be restricted, i will not object.
how about removing the term "flood" from the l2ping(2) man page, if the -f
semantics can't actually be called that way?
>
> thanks,
> max
--
a13x
More information about the freebsd-bluetooth
mailing list