On Thu, 28 Sep 2006 16:23:46 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > There is no reason to not allow non-admin users to query network
> > statistics and settings.
>
> NAK.
>
> Some functions in the past didn't like getting hit rapidly in succession.
>
> I wou
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 18:25:26 -0400
> GWOL now spits out a password for all users -> security risk. Ditto
> GEEPROM. GSET has been known to cause hangs if done in a tight loop, on
> some 10/100 cards, which is now permitted by any user. At the very
> l
David Miller wrote:
Secondarily, looping over reading all of the registers of the chip
might kill performance since the IO accesses compete with the
normal packet sending/receiving operations.
This can be true of any ethtool sub-ioctl that beats the registers, if
run in a tight loop. PHYs are
David Miller wrote:
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 13:17:04 -0700
I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
Dumping 64K worth of registers and blinking the LEDs should be
restricted. But I have no problem doing these checks in the d
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 15:03:40 -0700
> On Thu, 2006-09-28 at 14:53 -0700, David Miller wrote:
>
> > I've applied Stephen's patch with PHYS_ID removed from the
> > allowed list, thanks for the feedback.
>
> Can you remove GREGS as well? Allowing users to
From: James Morris <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 16:32:38 -0400 (EDT)
> On Thu, 28 Sep 2006, Michael Chan wrote:
>
> > I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
> > Dumping 64K worth of registers and blinking the LEDs should be
> > restricted.
>
> Out of
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 16:23:46 -0400
> NAK.
>
> Some functions in the past didn't like getting hit rapidly in succession.
>
> I would agree to this, but only after an exhaustive audit of each driver
> and each sub-ioctl. Right now, I only have confidence
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 13:17:04 -0700
> I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
> Dumping 64K worth of registers and blinking the LEDs should be
> restricted. But I have no problem doing these checks in the driver if
> necess
On Thu, 2006-09-28 at 14:53 -0700, David Miller wrote:
> I've applied Stephen's patch with PHYS_ID removed from the
> allowed list, thanks for the feedback.
Can you remove GREGS as well? Allowing users to dump all the registers
will be very problematic.
-
To unsubscribe from this list: send the
From: Auke Kok <[EMAIL PROTECTED]>
Date: Thu, 28 Sep 2006 12:56:25 -0700
> PHYS_ID pokes in hardware and makes it jump through hoops, in the case of
> some hardware
> this could create a local DOS attack (e1000 suffers fromt his, probably more
> if not all)
> where the NIC might stop receiving
On Thu, 2006-09-28 at 16:35 -0400, Jeff Garzik wrote:
> James Morris wrote:
> > On Thu, 28 Sep 2006, Michael Chan wrote:
> >
> >> I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
> >> Dumping 64K worth of registers and blinking the LEDs should be
> >> restricted.
> >
> > Out
Another example: registers often have sensitive information such as WoL
passwords or WEP keys stored in them.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
James Morris wrote:
On Thu, 28 Sep 2006, Michael Chan wrote:
I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
Dumping 64K worth of registers and blinking the LEDs should be
restricted.
Out of curiosity -- why?
In the past, dumping certain tg3 registers has led to lock-
On Thu, 28 Sep 2006, Michael Chan wrote:
> I'm against letting normal users do ETHTOOL_GREGS and ETHTOOL_PHYS_ID.
> Dumping 64K worth of registers and blinking the LEDs should be
> restricted.
Out of curiosity -- why?
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send t
Michael Chan wrote:
On Thu, 2006-09-28 at 12:25 -0700, Stephen Hemminger wrote:
+ /* Allow some commands to be done by anyone */
+ switch(ethcmd) {
+ case ETHTOOL_GSET:
+ case ETHTOOL_GDRVINFO:
+ case ETHTOOL_GREGS:
+ case ETHTOOL_GWOL:
+ case ETHTOOL_G
Stephen Hemminger wrote:
There is no reason to not allow non-admin users to query network
statistics and settings.
NAK.
Some functions in the past didn't like getting hit rapidly in succession.
I would agree to this, but only after an exhaustive audit of each driver
and each sub-ioctl. Righ
On Thu, 2006-09-28 at 12:25 -0700, Stephen Hemminger wrote:
> + /* Allow some commands to be done by anyone */
> + switch(ethcmd) {
> + case ETHTOOL_GSET:
> + case ETHTOOL_GDRVINFO:
> + case ETHTOOL_GREGS:
> + case ETHTOOL_GWOL:
> + case ETHTOOL_GMSGLVL:
> + case ET
Stephen Hemminger wrote:
There is no reason to not allow non-admin users to query network
statistics and settings.
--- linux-2.6.orig/net/core/ethtool.c
+++ linux-2.6/net/core/ethtool.c
@@ -806,13 +806,6 @@ int dev_ethtool(struct ifreq *ifr)
int rc;
unsigned long old_features;
On Thu, 28 Sep 2006, Stephen Hemminger wrote:
>
> There is no reason to not allow non-admin users to query network
> statistics and settings.
Acked-by: James Morris <[EMAIL PROTECTED]>
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
There is no reason to not allow non-admin users to query network
statistics and settings.
--- linux-2.6.orig/net/core/ethtool.c
+++ linux-2.6/net/core/ethtool.c
@@ -806,13 +806,6 @@ int dev_ethtool(struct ifreq *ifr)
int rc;
unsigned long old_features;
- /*
-* XXX
20 matches
Mail list logo
