Message-ID: <3C6A0F32.DE282B67@mandrakesoft.com>
Date: Wed, 13 Feb 2002 02:01:06 -0500
From: Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
MIME-Version: 1.0
To: "David S. Miller" <davem@redhat.com>
CC: ak@suse.de, linux-net@vger.kernel.org, netdev@oss.sgi.com,
   kuznet@ms2.inr.ac.ru
Subject: Re: IFF_PROMISC bug?
References: <20020212.205809.70219775.davem@redhat.com>
		<20020213071933.A22699@wotan.suse.de>
		<3C6A0817.B50EFC74@mandrakesoft.com> <20020212.223929.66060180.davem@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Content-Length: 1301
Lines: 39

"David S. Miller" wrote:
> 
>    From: Jeff Garzik <jgarzik@mandrakesoft.com>
>    Date: Wed, 13 Feb 2002 01:30:47 -0500
> 
>    Please help me understand the compatibility issues that prevent this,
>    given what I've just described...
> 
> What if you have a "promisc" count of 4, and SIOCSIFFLAGS asks to turn
> IFF_PROMISC off?  There is no logical way to perform such an
> operation.

Agreed.  Why must that affect SIOCGIFFLAGS reporting?

This is standard interface stuff, operation 'get' returns present state,
operation 'set' updates present state, if possible and allowed.

Whether ifconfig should be updated is a tangent issue (though a good
suggestion IMHO, David).  [further tangent, 'ifconfig eth0 promisc' may
follow a buggy code path?]

I still want to support IFF_PROMISC in SIOCGIFFLAGS because it is
clearly possible given the net driver API if nothing else, because it
broke a security program that called that ioctl to check for unwanted
promisc users[1], and because it might break other security-related
programs and scripts.  Sound OK?

Regards,

	Jeff


[1] i.e. the bug report that led me to this subject


-- 
Jeff Garzik      | "I went through my candy like hot oatmeal
Building 1024    |  through an internally-buttered weasel."
MandrakeSoft     |             - goats.com