Re: ipfw userland breaks again.

2002-12-18 Thread Dan Lukes
[EMAIL PROTECTED] wrote, On 12/14/02 23:13:

 I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable
 at module load time using a kernel environment variable.  Looks to me
 that it would do what you want.

	Should we think about kldload logic change ?
	Loading modules giving them a parameter string parsed on MOD_LOAD event
seems to be most generic way to do the things (not only with ipfw) ...
	The syscall allow arbitrary string as parameter, so it's not limited to
filename only, event routine declaration already has the void *data
variable, so the necesarry changes doesn't hit the userland (kldload)
nor modules code (unless they decide to parse the parameters).

Dan


--
Dan Lukes tel: +420 2 21914205, fax: +420 2 21914206
root of  FIONet, KolejNET,  webmaster  of www.freebsd.cz
AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-17 Thread Matthew Dillon
Huh.  Interesting.  The IP_FW_ADD test threw me but now that I
look at the code more closely it is only there because IP_FW_ADD
is a valid SOPT_GET op as well as a SOPT_SET op.  But FLUSH and friends
are SOPT_SET only.  Now I see how it works :-)

-Matt

:..
:: rule that, say, prevents spoofing is as bad as adding a rule that
:: allows everything through :-(
:
:This comment got me thinking.  The thinking lead to a lot of looking
:at code between compiles today, and more this evening.  It would
:appear that the test that was there was sufficient to deal with the
:cases that I was worried about.  Revisiting the change:
:
:-  if (sopt-sopt_name == IP_FW_ADD ||
:+  if (sopt-sopt_name == IP_FW_ADD || sopt-sopt_name == IP_FW_UNBREAK ||
:   (sopt-sopt_dir == SOPT_SET  sopt-sopt_name != IP_FW_RESETLOG)) {
:
:Earlier, we only allow IP_FW_{ADD,UNBREAK,RESETLOG,FLUSH,DELETE} for
:SOPT_SET requests and IP_FW_ADD (and a few others) for SOPT_GET
:requests.  Since GET + ADD is only case that isn't a SET that changes
:things, the == SOPT_SET takes care of the case that you added.
:
:For a while I thought one could do nasty things based on GET + FLUSH,
:say, but in raw_ip.c, we do the proper checks before calling
:ip_fw_ctl_ptr().
:
:So it looks like this code is subtle enough to have fooled both of
:us.  This one change isn't needed for this patch.
:
:Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-17 Thread Ruslan Ermilov
On Tue, Dec 17, 2002 at 10:23:15AM -0800, Matthew Dillon wrote:
 Huh.  Interesting.  The IP_FW_ADD test threw me but now that I
 look at the code more closely it is only there because IP_FW_ADD
 is a valid SOPT_GET op as well as a SOPT_SET op.  But FLUSH and friends
 are SOPT_SET only.  Now I see how it works :-)
 
``cvs log -r1.145 -r1.147 ip_fw.c'' for more details.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg48927/pgp0.pgp
Description: PGP signature


Re: ipfw userland breaks again.

2002-12-16 Thread Ruslan Ermilov
On Sun, Dec 15, 2002 at 08:47:23PM +, Nik Clayton wrote:
 On Sun, Dec 15, 2002 at 11:08:01AM -0800, Matthew Dillon wrote:
  
  :
  ::This is complete BULLSHIT, Warner.  
  :
  :Your attitude it totally unacceptible.  Learn to play well with
  :others, or get the fuck out of the project.
  
   Really?  You think I should learn to play well with others?  You
   think it's appropriate to request that I spend a man week rewriting
   an API?  You really do?  You think it's appropriate to bring up a 
   bogus security issue when its obvious that no security issue exists,
   abusing your power in that manner is playing well with others?  This
   is Warner of core?
 
 I think it's more appropriate if you put 
 
 options IPFIREWALL_DEFAULT_TO_ACCEPT
 
 on any boxes where you're running test code.  That's much more
 acceptable than committing a kludge with a poor choice of name after
 minimal discussion when efforts would be better spent working on other
 rough edges in the run up to 5-release.
 
There were times, even within RELENG_4 lifecycle, when IPFW ABI
was broken, making it really hard to remotely upgrade IPFW boxes,
as we're required to boot with the new kernel before doing an
installworld.  It once costed me about 12 hours of downtime of
our Australian production box.

This is from the -STABLE's UPDATING:

20010109:
ipfw interface changed.  Make sure that the userland and kernel match
or you won't have the firewall rules you think you do.

19990620:
IPFW uid/gid-based filtering support has been committed. This
breaks binary compatibility with previous copies of
ipfw(8). Any utilities using the ioctl()s of ipfw (especially
ipfw(8)) need to be recompiled with the newest headers
installed.

19980725:
The ipfw interface to the kernel has changed.  You will need to
recompile ipfw programs for the new kernel.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg48844/pgp0.pgp
Description: PGP signature


Re: ipfw userland breaks again.

2002-12-16 Thread Ruslan Ermilov
On Sat, Dec 14, 2002 at 02:09:13PM -0800, Matthew Dillon wrote:
 
 :
 :On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote:
 : then, as usual, IPFW with the new kernel and
 : old world fails utterly and now the fragging machine can't access the
 :
 :Hear hear!!  I am  tempted to have /sbin/ipfw moved to src/sys.
 
 How about something like this (patch enclosed).  If there are no
 objections I will commit it along with a documentation update, and
 maybe also add some RC code give the sysad a chance to ipfw unbreak if
 ipfw otherwise fails during the boot sequence.
 
Matt,

How this could be helpful in a remote upgrade scenario that has
IPFW ABI incompatibility issues?

One alternative approach would be to not compile IPFW into a
kernel but rather have it loaded as a module.  Then, you
install new kernel, edit out ipfw_enable=YES for the time
being, reboot with the new kernel, installworld, edit
ipfw_enable=YES back in, reboot, and you're done.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg48845/pgp0.pgp
Description: PGP signature


Re: ipfw userland breaks again.

2002-12-16 Thread Julian Elischer


On Mon, 16 Dec 2002, Ruslan Ermilov wrote:

 On Sat, Dec 14, 2002 at 02:09:13PM -0800, Matthew Dillon wrote:
  
  :
  :On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote:
  : then, as usual, IPFW with the new kernel and
  : old world fails utterly and now the fragging machine can't access the
  :
  :Hear hear!!  I am  tempted to have /sbin/ipfw moved to src/sys.
  
  How about something like this (patch enclosed).  If there are no
  objections I will commit it along with a documentation update, and
  maybe also add some RC code give the sysad a chance to ipfw unbreak if
  ipfw otherwise fails during the boot sequence.
  
 Matt,
 
 How this could be helpful in a remote upgrade scenario that has
 IPFW ABI incompatibility issues?
 
 One alternative approach would be to not compile IPFW into a
 kernel but rather have it loaded as a module.  Then, you
 install new kernel, edit out ipfw_enable=YES for the time
 being, reboot with the new kernel, installworld, edit
 ipfw_enable=YES back in, reboot, and you're done.


I think having ipfw as a module doesn't get you fwd or divert.
(I may be wrong)

 
 
 Cheers,
 -- 
 Ruslan ErmilovSysadmin and DBA,
 [EMAIL PROTECTED] Sunbay Software AG,
 [EMAIL PROTECTED]FreeBSD committer,
 +380.652.512.251  Simferopol, Ukraine
 
 http://www.FreeBSD.orgThe Power To Serve
 http://www.oracle.com Enabling The Information Age
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-16 Thread Matthew Dillon

:How this could be helpful in a remote upgrade scenario that has
:IPFW ABI incompatibility issues?
:
:One alternative approach would be to not compile IPFW into a
:kernel but rather have it loaded as a module.  Then, you
:install new kernel, edit out ipfw_enable=3DYES for the time
:being, reboot with the new kernel, installworld, edit
:ipfw_enable=3DYES back in, reboot, and you're done.
:
:
:Cheers,
:--=20
:Ruslan Ermilov Sysadmin and DBA,

Well, the basic problem is that you don't actually know when the IPFW
API is going to break.  I do incremental upgrades most of the time
and IPFW breaks maybe once every 5 upgrades.  So for a manual upgrade
it can be a severe inconvenience to have to deal with the possibility
every time you upgrade.  For an automated upgrade one can always 
automate and 'ipfw unbreak' (or 'ipfw open' as John just suggested to me)
is not needed.

What this patch does is allow you to upgrade via a serial console
normally, without having to pay particular attention to IPFW, and
if the IPFW API happens to break you can then simply 'ipfw unbreak' to
get access to the network and then fix whatever broke.

The only viable alternative that I've heard so far on the lists, 
other then 'Matt should rewrite the API so it doesn't break' is to
have the installkernel and installworld targets check for ipfw
incompatibility and install the new ipfw.  Of course, this doesn't help
if you have to revert the kernel.  I still prefer the failsafe my
solution supplies.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-16 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
: Here's a new patch.  But there isn't much of a point if we do not
: also disallow ipfw DELETE and FLUSH.  And the pipe config commands
: as well as anything else that changes the firewall state.  Firewalls
: are there to protect the systems behind them.  I think deleting the
: rule that, say, prevents spoofing is as bad as adding a rule that
: allows everything through :-(

This comment got me thinking.  The thinking lead to a lot of looking
at code between compiles today, and more this evening.  It would
appear that the test that was there was sufficient to deal with the
cases that I was worried about.  Revisiting the change:

-   if (sopt-sopt_name == IP_FW_ADD ||
+   if (sopt-sopt_name == IP_FW_ADD || sopt-sopt_name == IP_FW_UNBREAK ||
(sopt-sopt_dir == SOPT_SET  sopt-sopt_name != IP_FW_RESETLOG)) {

Earlier, we only allow IP_FW_{ADD,UNBREAK,RESETLOG,FLUSH,DELETE} for
SOPT_SET requests and IP_FW_ADD (and a few others) for SOPT_GET
requests.  Since GET + ADD is only case that isn't a SET that changes
things, the == SOPT_SET takes care of the case that you added.

For a while I thought one could do nasty things based on GET + FLUSH,
say, but in raw_ip.c, we do the proper checks before calling
ip_fw_ctl_ptr().

So it looks like this code is subtle enough to have fooled both of
us.  This one change isn't needed for this patch.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:

: :I disagree with committing this hack; keep it as a local mod if you must.
: :
: :As to the problem; don't wait for Luigi to fix the ABI problems, do it
: :yourself.  Good things happen when folks are PO'd and won't settle for the
: :status quo.
: :
: :Sam
: 
: I'm sorry you disagree, but it doesn't change my position.  I am not
: in the business of rewriting other people's APIs.  If it means so much
: to you, YOU go and fix it.  No?  Then don't complain about my fix.  It's
: no skin off your nose and it will prevent a lot of future headaches,
: especially if the RC system makes it nice and friendly.

I don't like the patch from a security standpoint.  It makes it to
easy to turn off a firewall.  If you want to be that stupid about
security, you should just make the default be 'accept all' and be done
with it.  I'm opposed to this patch unless you can get the security
officer to sign off on it.  The defaults are there for a reason so
that we fail 'safe' from a security point of view.

The real fix is to fix the abi problems.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Matthew Dillon
:I don't like the patch from a security standpoint.  It makes it to
:easy to turn off a firewall.  If you want to be that stupid about
:security, you should just make the default be 'accept all' and be done
:with it.  I'm opposed to this patch unless you can get the security
:officer to sign off on it.  The defaults are there for a reason so
:that we fail 'safe' from a security point of view.
:
:The real fix is to fix the abi problems.
:
:Warner

This is complete BULLSHIT, Warner.  This patch exists precisely so
the firewall can be turned on in secure mode.  It does not make it
any easier to turn off then adding a rule:

ipfw add 2 allow all from any to any

So don't give me this bullshit about the patch being a security issue.
YOU KNOW IT ISN'T.

Now you are forcing me to go to core.  It's absolutely ridiculous and
you know it.  Goddamn it, next time I won't even bother posting if all
I get is this sort of crap.

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Matthew Dillon
:
:The real fix is to fix the abi problems.
:
:Warner

Doh!!Thanks for volunteering to fix the ABI problems.  No?  You
don't want to do it?  Gee, I saw that one coming a mile away!
THEN DON'T COMPLAIN.

This is not a fucking security issue.  This is a patch that solves 
a major irritation, nothing more, nothing less, except some people 
can't stand an 8-line fix to the problem apparently.

-Matt

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Anders Nordby
Hi,

On Sun, Dec 15, 2002 at 10:26:22AM -0800, Matthew Dillon wrote:
 This is complete BULLSHIT, Warner.  This patch exists precisely so
 the firewall can be turned on in secure mode.  It does not make it
 any easier to turn off then adding a rule:
 
 ipfw add 2 allow all from any to any
 
 So don't give me this bullshit about the patch being a security issue.
 YOU KNOW IT ISN'T.
 
 Now you are forcing me to go to core.  It's absolutely ridiculous and
 you know it.  Goddamn it, next time I won't even bother posting if all
 I get is this sort of crap.

How about sending the patch to the Technical Review Board, trb@ instead.

Thanks.

Cheers,

-- 
Anders.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Matthew Dillon

:How about sending the patch to the Technical Review Board, trb@ instead.
:
:Thanks.
:
:Cheers,
:
:-- 
:Anders.

Getting bored sitting on your buns?  It's already gone to core and,
frankly, I think core is the proper forum now that Warner has declared
it a security issue (when it obviously isn't.  How easy is it to do
an ipfw add 2 allow all from any to any?  It's ludicrous to call it
a security issue).

I really don't mind people disagreeing, but I do mind it when people
believe that the proper solution is for Matt Dillon to spend a man week
fixing a major API that he didn't write instead of comitting an 8 line
patch that deals with the issue well enough so sysads don't have to
pull their hair out every time it happens. 

As I said before, I have no problem with the patch being removed once
the API is fixed, but I am NOT the guy who should be rewriting the API
and, frankly, it is inappropriate for anyone to suggest that I should
be if they themselves are not willing to sit down in front of a 
keyboard and come up with a committable solution of their own.  So far
all I've heard are utterly trivial complaints from people who aren't
willing to code up a solution themselves.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Miguel Mendez
On Sun, 15 Dec 2002 10:26:22 -0800 (PST)
Matthew Dillon [EMAIL PROTECTED] wrote:

Hi,

must...resist...


 So don't give me this bullshit about the patch being a security
 issue. YOU KNOW IT ISN'T.

No, Warner has a point, that patch is simply bandaid (albeit a good
one).

 Now you are forcing me to go to core.  It's absolutely ridiculous
 and you know it.  Goddamn it, next time I won't even bother
 posting if all I get is this sort of crap.

I know I'm gonna get flamed for this, but you know what's ridiculous? All
the flamage you've brought up on the issue. You're a great hacker Matt,
just keep it easy and don't take it so personal.

Cheers,
-- 
Miguel Mendez - [EMAIL PROTECTED]
GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt
EnergyHQ :: http://www.energyhq.tk
Of course it runs NetBSD!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread M. Warner Losh
:This is complete BULLSHIT, Warner.  

Your attitude it totally unacceptible.  Learn to play well with
others, or get the fuck out of the project.

I am *NOT* blocking you.  I'm telling you you need to get the SO's
sign off to make sure that there isn't a security issue because the
current defaults were set by the so.  If you don't like that, then I
suggest that you get over yourself and find someplace else to play.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
: :
: :The real fix is to fix the abi problems.
: :
: :Warner
: 
: Doh!!Thanks for volunteering to fix the ABI problems.  No?  You
: don't want to do it?  Gee, I saw that one coming a mile away!
: THEN DON'T COMPLAIN.

GET OVER YOURSELF.  YOUR CONTIRBUTES ARE NOT GREAT ENOUGH THAT I WILL
TOLERATE THIS BULLSHIT ANYMORE.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Matthew Dillon

:
:In message: [EMAIL PROTECTED]
:Matthew Dillon [EMAIL PROTECTED] writes:
:: :
:: :The real fix is to fix the abi problems.
:: :
:: :Warner
:: 
:: Doh!!Thanks for volunteering to fix the ABI problems.  No?  You
:: don't want to do it?  Gee, I saw that one coming a mile away!
:: THEN DON'T COMPLAIN.
:
:GET OVER YOURSELF.  YOUR CONTIRBUTES ARE NOT GREAT ENOUGH THAT I WILL
:TOLERATE THIS BULLSHIT ANYMORE.
:
:Warner

Bullshit is exactly what it is Warner, but I'm not the one spouting 
it.  When all is said and done, this patch is utterly trivial and
doesn't hurt anyone.  I have said on multiple occassions that it
can be removed when the API is fixed, but I am not willing to wait
for the API to be fixed because the API has been an open issue for,
what, a year now?  More?  If you want to fix the API then you should
go and fix it.  I should have just comitted the damn thing 
rather then ask for a review on the mailing list.  I should know better
by now.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Matthew Dillon

:
::This is complete BULLSHIT, Warner.  
:
:Your attitude it totally unacceptible.  Learn to play well with
:others, or get the fuck out of the project.
:
:I am *NOT* blocking you.  I'm telling you you need to get the SO's
:sign off to make sure that there isn't a security issue because the
:current defaults were set by the so.  If you don't like that, then I
:suggest that you get over yourself and find someplace else to play.
:
:Warner

This is not a security issue.  Why do you think it is?  How is
'ipfw unbreak' any different from 'ipfw add 2 allow all from any to any'?
(Other then the fact that unbreak is immune from API changes).

Have you even bothered to read the patch?

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Matthew Dillon

:
::This is complete BULLSHIT, Warner.  
:
:Your attitude it totally unacceptible.  Learn to play well with
:others, or get the fuck out of the project.

 Really?  You think I should learn to play well with others?  You
 think it's appropriate to request that I spend a man week rewriting
 an API?  You really do?  You think it's appropriate to bring up a 
 bogus security issue when its obvious that no security issue exists,
 abusing your power in that manner is playing well with others?  This
 is Warner of core?

 When people say and do reasonable things I am a reasonable guy.  When
 people say and do unreasonable things then I fight tooth and nail. 
 It's that simple.  If you don't like it, then tough.  There is nothing
 unreasonable about this patch.  NOTHING.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
: 
: :
: ::This is complete BULLSHIT, Warner.  
: :
: :Your attitude it totally unacceptible.  Learn to play well with
: :others, or get the fuck out of the project.
: :
: :I am *NOT* blocking you.  I'm telling you you need to get the SO's
: :sign off to make sure that there isn't a security issue because the
: :current defaults were set by the so.  If you don't like that, then I
: :suggest that you get over yourself and find someplace else to play.
: :
: :Warner
: 
: This is not a security issue.  Why do you think it is?  How is
: 'ipfw unbreak' any different from 'ipfw add 2 allow all from any to any'?
: (Other then the fact that unbreak is immune from API changes).
: 
: Have you even bothered to read the patch?

Yes, I have.  It potentially has security implications because it is a
security part of the system.  That's why I think it would be valuable
to get the SO's input on what you are doing.  I've read the patch.  It
makes it possible with one ioctl to turn off the firewall to allow you
to use the system.  That needs careful reviewed.

In fact, it has one flaw.  You'll find on lines

/*
 * Disallow modifications in really-really secure mode, but still allow
 * the logging counters to be reset.
 */
if (sopt-sopt_name == IP_FW_ADD ||
(sopt-sopt_dir == SOPT_SET  sopt-sopt_name != IP_FW_RESETLOG)) {
#if __FreeBSD_version = 500034
error = securelevel_ge(sopt-sopt_td-td_ucred, 3);
if (error)
return (error);
#else /* FreeBSD 4.x */
if (securelevel = 3)
return (EPERM);
#endif
}

which you haven't changed.  This strikes me as a danger operation to
allow in high security mode, so there likely needs to be some changes
assocaited with the above lines (like an || sopt-sopt_name ==
IP_FW_UNBREAK in the above).  Otherwise, an attacker would be able to
turn off the ipfw stuff at a high security level.

I'm not trying to get in your way Matt, I'm just saying that there
needs to be a little discussion on this kludge if you aren't going to
fix the real, underlying problem,  ok?

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Matthew Dillon [EMAIL PROTECTED] writes:
:  When people say and do reasonable things I am a reasonable guy.  When
:  people say and do unreasonable things then I fight tooth and nail. 
:  It's that simple.  If you don't like it, then tough.  There is nothing
:  unreasonable about this patch.  NOTHING.

I've answered this in other email, but you need to expand the check at
the top of ipfw_ctl to include this new message as one of the ones
that is disallowed at high security levels.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Scott Long
Matthew Dillon wrote:

 [ useless drivel removed ]

There's still a TODO list for 5.0.  It was even mailed out to 
developers@ this morning.  If you have time to spare in your day, please 
focus your attention to that right now.

Also, fixing the ipfw2 abi is probably a good item to put on the list 
for getting 5.x to 5-STABLE.  Please don't waste time with band-aids 
that will make people forget that ipfw2 needs attention.

Scott


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


Re: ipfw userland breaks again.

2002-12-15 Thread Matthew Dillon

:Also, fixing the ipfw2 abi is probably a good item to put on the list 
:for getting 5.x to 5-STABLE.  Please don't waste time with band-aids 
:that will make people forget that ipfw2 needs attention.
:
:Scott

This is a reasonable line of argument but my opinion is that it
hasn't been fixed for a long time now and unless someone decides
they really want to tackle the issue soon it isn't going to be
fixed for a long time to come, and we shouldn't continue to create
a major hassle for developers and sysads that hit up against
the issue.

I mean, hey, if someone asked me to rename the command from 
'ipfw unbreak' to 'ipfw somelonggobblygookthatyouhavetocutandpaste'
I'm willing to do that too :-)  But we need either the API fixed or
this hack and, right now, the only person willing to do anything is
me and my buddy Hack.  If someone stood up and said I will take on
fixing the API but it will take a month then that's fine with me,
I would not feel that I would have to commit this now.  But so far
nobody has stood up and said that.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Garrett Wollman
On Sun, 15 Dec 2002 10:26:22 -0800 (PST), Matthew Dillon 
[EMAIL PROTECTED] said:

 Now you are forcing me to go to core.  It's absolutely ridiculous and
 you know it.  Goddamn it, next time I won't even bother posting if all
 I get is this sort of crap.

All the better, if you refuse to be civil to your fellow developers.

-GAWollman


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Matthew Dillon
:I've answered this in other email, but you need to expand the check at
:the top of ipfw_ctl to include this new message as one of the ones
:that is disallowed at high security levels.
:
:Warner

Here's a new patch.  But there isn't much of a point if we do not
also disallow ipfw DELETE and FLUSH.  And the pipe config commands
as well as anything else that changes the firewall state.  Firewalls
are there to protect the systems behind them.  I think deleting the
rule that, say, prevents spoofing is as bad as adding a rule that
allows everything through :-(

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


Index: sbin/ipfw/ipfw.8
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw.8,v
retrieving revision 1.116
diff -u -r1.116 ipfw.8
--- sbin/ipfw/ipfw.826 Nov 2002 19:51:40 -  1.116
+++ sbin/ipfw/ipfw.814 Dec 2002 22:17:17 -
@@ -21,6 +21,9 @@
 .Cm flush
 .Nm
 .Op Fl q
+.Cm unbreak
+.Nm
+.Op Fl q
 .Brq Cm delete | zero | resetlog
 .Op Cm set
 .Op Ar number ...
@@ -179,6 +182,16 @@
 and
 .Cm resetlog
 commands.
+.Pp
+When upgrading your kernel and userland you may wind up in a situation
+where
+.Nm
+is unable to add rules due to a kernel/userland mismatch.  If you depend
+on NFS as your install source this can result in a no-win situation.
+You can use the
+.Cm unbreak
+command to flush and install a simple pass-through rule that will allow
+you to get your network up and running so you can resolve the problem.
 .Pp
 Also, each rule belongs to one of 32 different
 .Em sets
Index: sbin/ipfw/ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.18
diff -u -r1.18 ipfw2.c
--- sbin/ipfw/ipfw2.c   26 Nov 2002 22:53:14 -  1.18
+++ sbin/ipfw/ipfw2.c   14 Dec 2002 22:08:11 -
@@ -3307,6 +3307,30 @@
printf(Flushed all %s.\n, do_pipe ? pipes : rules);
 }
 
+static void
+unbreak()
+{
+   if (!do_force  !do_quiet) { /* need to ask user */
+   int c;
+
+   printf(Are you sure? [yn] );
+   fflush(stdout);
+   do {
+   c = toupper(getc(stdin));
+   while (c != '\n'  getc(stdin) != '\n')
+   if (feof(stdin))
+   return; /* and do not flush */
+   } while (c != 'Y'  c != 'N');
+   printf(\n);
+   if (c == 'N')   /* user said no */
+   return;
+   }
+   if (setsockopt(s, IPPROTO_IP, IP_FW_UNBREAK, NULL, 0)  0)
+   err(EX_UNAVAILABLE, setsockopt(IP_FW_UNBREAK));
+   if (!do_quiet)
+   printf(Flushed all rules and installed a pass-through.\n);
+}
+
 static int
 ipfw_main(int ac, char **av)
 {
@@ -3398,6 +3422,8 @@
delete(ac, av);
else if (!strncmp(*av, flush, strlen(*av)))
flush();
+   else if (!strncmp(*av, unbreak, strlen(*av)))
+   unbreak();
else if (!strncmp(*av, zero, strlen(*av)))
zero(ac, av);
else if (!strncmp(*av, resetlog, strlen(*av)))
Index: sys/netinet/in.h
===
RCS file: /home/ncvs/src/sys/netinet/in.h,v
retrieving revision 1.73
diff -u -r1.73 in.h
--- sys/netinet/in.h29 Oct 2002 16:46:13 -  1.73
+++ sys/netinet/in.h14 Dec 2002 21:32:07 -
@@ -393,6 +393,7 @@
 #defineIP_FW_ZERO  53   /* clear single/all firewall counter(s) */
 #defineIP_FW_GET   54   /* get entire firewall rule chain */
 #defineIP_FW_RESETLOG  55   /* reset logging counters */
+#defineIP_FW_UNBREAK   56   /* flush and install a pass-thru rule */
 
 #defineIP_DUMMYNET_CONFIGURE   60   /* add/configure a dummynet pipe */
 #defineIP_DUMMYNET_DEL 61   /* delete a dummynet pipe from chain */
Index: sys/netinet/ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.20
diff -u -r1.20 ip_fw2.c
--- sys/netinet/ip_fw2.c15 Dec 2002 09:44:02 -  1.20
+++ sys/netinet/ip_fw2.c15 Dec 2002 19:36:54 -
@@ -2457,7 +2457,7 @@
 * Disallow modifications in really-really secure mode, but still allow
 * the logging counters to be reset.
 */
-   if (sopt-sopt_name == IP_FW_ADD ||
+   if (sopt-sopt_name == IP_FW_ADD || sopt-sopt_name == IP_FW_UNBREAK ||
(sopt-sopt_dir == SOPT_SET  sopt-sopt_name != IP_FW_RESETLOG)) {
 #if __FreeBSD_version = 500034
error = securelevel_ge(sopt-sopt_td-td_ucred, 3);
@@ -2535,6 +2535,7 @@
break;
 
case IP_FW_FLUSH:
+   

Re: ipfw userland breaks again.

2002-12-15 Thread Matthew Dillon

:
:On Sun, 15 Dec 2002 10:26:22 -0800 (PST), Matthew Dillon 
:[EMAIL PROTECTED] said:
:
: Now you are forcing me to go to core.  It's absolutely ridiculous and
: you know it.  Goddamn it, next time I won't even bother posting if all
: I get is this sort of crap.
:
:All the better, if you refuse to be civil to your fellow developers.
:
:-GAWollman

If people are reasonable with me, I am reasonable right back.  If
people are unreasonable, they shouldn't expect me to be reasonable
in response.  It's really that simple.

-Matt

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Garrett Wollman
On Sun, 15 Dec 2002 11:41:26 -0800 (PST), Matthew Dillon 
[EMAIL PROTECTED] said:

 If people are reasonable with me, I am reasonable right back.  If
 people are unreasonable, they shouldn't expect me to be reasonable
 in response.  It's really that simple.

As a FreeBSD developer, you are expected to be civil to your fellow
developers at all times, as stated in the committers' rules.  If you
can't manage that, please find another project.

-GAWollman


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Nate Lawson
On Sun, 15 Dec 2002, Matthew Dillon wrote:
 Here's a new patch.  But there isn't much of a point if we do not
 also disallow ipfw DELETE and FLUSH.  And the pipe config commands
 as well as anything else that changes the firewall state.  Firewalls
 are there to protect the systems behind them.  I think deleting the
 rule that, say, prevents spoofing is as bad as adding a rule that
 allows everything through :-(

One other avenue would be to stick a temporary check for ABI compat in
installworld before overwriting ipfw.  Or for the next few releases, build
both ipfw1 and ipfw2 and install both (say, symlinking ipfw - ipfw2 by
default).  You could fall back to ipfw1 if ipfw2 returns an error code in
rc scripts.  I'd prefer this kind of hack in the install/rc process, not
in a new API.

Regarding civility to developers, there are a ton of frustrating things in
any project.  I think civility should be the response given to both
reasonable and unreasonable people.  If they are unreasonable, giving a
reasonable response just makes them look bad.

-Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Matthew Dillon
   What it comes down to is what developers are willing to do.  My 
   contribution is 'ipfw unbreak'.  If someone else has a solution that
   they are willing to work on and commit in the next four weeks, then
   fine.  But if nobody is willing to work on and commit another solution
   in the next four weeks then I should be able to commit my solution now,
   which really isn't all that bad hack or not.

   Any build-related solution would have to be handled by both installworld
   and installkernel.  Consider the fact that most developers, when working
   on -current, install the kernel far more often then they install the world.
   An API check during the installkernel would work almost as well for my
   own purposes as 'ipfw unbreak'.  It doesn't provide a failsafe but it
   does handle the most common installation case.

   Note that this solution may not be quite as simple as it appears, since
   -current may be built on a -stable box so compiling up an out-of-date
   ipfw is not entirely trivial.

   My current solution is on the table.  I see no others on the table at
   the moment.

-Matt

:One other avenue would be to stick a temporary check for ABI compat in
:installworld before overwriting ipfw.  Or for the next few releases, build
:both ipfw1 and ipfw2 and install both (say, symlinking ipfw - ipfw2 by
:default).  You could fall back to ipfw1 if ipfw2 returns an error code in
:rc scripts.  I'd prefer this kind of hack in the install/rc process, not
:in a new API.
:
:Regarding civility to developers, there are a ton of frustrating things in
:any project.  I think civility should be the response given to both
:reasonable and unreasonable people.  If they are unreasonable, giving a
:reasonable response just makes them look bad.
:
:-Nate

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-15 Thread Nik Clayton
On Sun, Dec 15, 2002 at 11:08:01AM -0800, Matthew Dillon wrote:
 
 :
 ::This is complete BULLSHIT, Warner.  
 :
 :Your attitude it totally unacceptible.  Learn to play well with
 :others, or get the fuck out of the project.
 
  Really?  You think I should learn to play well with others?  You
  think it's appropriate to request that I spend a man week rewriting
  an API?  You really do?  You think it's appropriate to bring up a 
  bogus security issue when its obvious that no security issue exists,
  abusing your power in that manner is playing well with others?  This
  is Warner of core?

I think it's more appropriate if you put 

options IPFIREWALL_DEFAULT_TO_ACCEPT

on any boxes where you're running test code.  That's much more
acceptable than committing a kludge with a poor choice of name after
minimal discussion when efforts would be better spent working on other
rough edges in the run up to 5-release.

N
-- 
FreeBSD: The Power to Serve  http://www.freebsd.org/   (__)
FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',)
  \/  \ ^
   --- 15B8 3FFC DDB4 34B0 AA5F  94B7 93A8 0764 2C37 E375 --- .\._/_)



msg48806/pgp0.pgp
Description: PGP signature


Re: ipfw userland breaks again.

2002-12-14 Thread David O'Brien
On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote:
 then, as usual, IPFW with the new kernel and
 old world fails utterly and now the fragging machine can't access the

Hear hear!!  I am  tempted to have /sbin/ipfw moved to src/sys.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-14 Thread Matthew Dillon

:
:On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote:
: then, as usual, IPFW with the new kernel and
: old world fails utterly and now the fragging machine can't access the
:
:Hear hear!!  I am  tempted to have /sbin/ipfw moved to src/sys.

How about something like this (patch enclosed).  If there are no
objections I will commit it along with a documentation update, and
maybe also add some RC code give the sysad a chance to ipfw unbreak if
ipfw otherwise fails during the boot sequence.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


Index: sbin/ipfw/ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.18
diff -u -r1.18 ipfw2.c
--- sbin/ipfw/ipfw2.c   26 Nov 2002 22:53:14 -  1.18
+++ sbin/ipfw/ipfw2.c   14 Dec 2002 22:08:11 -
@@ -3307,6 +3307,30 @@
printf(Flushed all %s.\n, do_pipe ? pipes : rules);
 }
 
+static void
+unbreak()
+{
+   if (!do_force  !do_quiet) { /* need to ask user */
+   int c;
+
+   printf(Are you sure? [yn] );
+   fflush(stdout);
+   do {
+   c = toupper(getc(stdin));
+   while (c != '\n'  getc(stdin) != '\n')
+   if (feof(stdin))
+   return; /* and do not flush */
+   } while (c != 'Y'  c != 'N');
+   printf(\n);
+   if (c == 'N')   /* user said no */
+   return;
+   }
+   if (setsockopt(s, IPPROTO_IP, IP_FW_UNBREAK, NULL, 0)  0)
+   err(EX_UNAVAILABLE, setsockopt(IP_FW_UNBREAK));
+   if (!do_quiet)
+   printf(Flushed all rules and installed a pass-through.\n);
+}
+
 static int
 ipfw_main(int ac, char **av)
 {
@@ -3398,6 +3422,8 @@
delete(ac, av);
else if (!strncmp(*av, flush, strlen(*av)))
flush();
+   else if (!strncmp(*av, unbreak, strlen(*av)))
+   unbreak();
else if (!strncmp(*av, zero, strlen(*av)))
zero(ac, av);
else if (!strncmp(*av, resetlog, strlen(*av)))
Index: sys/netinet/in.h
===
RCS file: /home/ncvs/src/sys/netinet/in.h,v
retrieving revision 1.73
diff -u -r1.73 in.h
--- sys/netinet/in.h29 Oct 2002 16:46:13 -  1.73
+++ sys/netinet/in.h14 Dec 2002 21:32:07 -
@@ -393,6 +393,7 @@
 #defineIP_FW_ZERO  53   /* clear single/all firewall counter(s) */
 #defineIP_FW_GET   54   /* get entire firewall rule chain */
 #defineIP_FW_RESETLOG  55   /* reset logging counters */
+#defineIP_FW_UNBREAK   56   /* flush and install a pass-thru rule */
 
 #defineIP_DUMMYNET_CONFIGURE   60   /* add/configure a dummynet pipe */
 #defineIP_DUMMYNET_DEL 61   /* delete a dummynet pipe from chain */
Index: sys/netinet/ip_fw2.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.19
diff -u -r1.19 ip_fw2.c
--- sys/netinet/ip_fw2.c20 Nov 2002 19:07:27 -  1.19
+++ sys/netinet/ip_fw2.c14 Dec 2002 21:41:52 -
@@ -2535,6 +2535,7 @@
break;
 
case IP_FW_FLUSH:
+   case IP_FW_UNBREAK:
/*
 * Normally we cannot release the lock on each iteration.
 * We could do it here only because we start from the head all
@@ -2551,6 +2552,22 @@
s = splimp();
free_chain(layer3_chain, 0 /* keep default rule */);
splx(s);
+
+   /*
+* If unbreaking the rulechain, which a sysad may have to do
+* if IP_FW_ADD fails due to a userland/kernelland mismatch,
+* install a pass-through rule.
+*/
+   if (sopt-sopt_name == IP_FW_UNBREAK) {
+   rule = (struct ip_fw *)rule_buf; /* XXX do a malloc */
+   bzero(rule, sizeof(*rule));
+   rule-rulenum = 2;
+   rule-cmd_len = 1;
+   rule-set = 1;
+   rule-cmd[0].len = 1;
+   rule-cmd[0].opcode = O_ACCEPT;
+   error = add_rule(layer3_chain, rule);
+   }
break;
 
case IP_FW_ADD:
Index: sys/netinet/raw_ip.c
===
RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v
retrieving revision 1.107
diff -u -r1.107 raw_ip.c
--- sys/netinet/raw_ip.c20 Nov 2002 19:00:54 -  1.107
+++ sys/netinet/raw_ip.c14 Dec 2002 21:33:58 -
@@ -399,6 +399,7 @@
  

Re: ipfw userland breaks again.

2002-12-14 Thread Maxime Henrion
Matthew Dillon wrote:
 
 :
 :On Sat, Dec 14, 2002 at 12:38:13PM -0800, Matthew Dillon wrote:
 : then, as usual, IPFW with the new kernel and
 : old world fails utterly and now the fragging machine can't access the
 :
 :Hear hear!!  I am  tempted to have /sbin/ipfw moved to src/sys.
 
 How about something like this (patch enclosed).  If there are no
 objections I will commit it along with a documentation update, and
 maybe also add some RC code give the sysad a chance to ipfw unbreak if
 ipfw otherwise fails during the boot sequence.

I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable
at module load time using a kernel environment variable.  Looks to me
that it would do what you want.

Maxime

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-14 Thread Matthew Dillon

:
:I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable
:at module load time using a kernel environment variable.  Looks to me
:that it would do what you want.
:
:Maxime

No, this isn't what I want.  I want something that can be articulated
without having to reboot the whole system.  The last time this happened
to me, which was today, I had to reboot the system FIVE times before I
got the network working again.  For example, I tried rebooting into
an old kernel and the fragging boot code tried to load the new kernel's
ACPI module (actually it tried to load BOTH the old and new kernel's
ACPI modules), and it panic'd of course.  It took five attempts before I
managed to get something that worked with the network up and then I
had to reboot *AGAIN* to do the installworld with the new kernel.

It's beginning to feel like a windows install!

When you are sitting at a boot prompt and have no access to manual
pages and such, and no in-boot-help that's significant enough to
be worthwhile, it's no help tearing your hair out trying to remember
the name of the stupid boot variable.  The last thing I want is yet
another undocumented or hard-to-find boot variable.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-14 Thread Maxime Henrion
Matthew Dillon wrote:
 :I have a patch here which makes the IPFIREWALL_DEFAULT_TO_ACCEPT tunable
 :at module load time using a kernel environment variable.  Looks to me
 :that it would do what you want.
 
 No, this isn't what I want.  I want something that can be articulated
 without having to reboot the whole system.

You don't need to reboot with this patch.  As I already said it, it's a
*module load time* tunable.  So if you use ipfw as a module, it will do
what you want.  If you don't, it's of course useless.

Now I would really dislike seeing your patch in the tree, since I
consider it's a rather crude hack to circumvent the ABI problems of
ipfw.  As I've already said to luigi in private e-mail (I would be
surprised if this hasn't been already discussed in the lists as well), 
the proper way to fix this problem is to separate the kernel and
userland structures of ipfw, and add versioning to the struct.

This can be done without even breaking the ABI again, since several
pointers in the kernel structures are useless to userland (like the next
field) and can be reused to implement structure versioning.

Cheers,
Maxime

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-14 Thread Matthew Dillon

:Now I would really dislike seeing your patch in the tree, since I
:consider it's a rather crude hack to circumvent the ABI problems of
:ipfw.  As I've already said to luigi in private e-mail (I would be
:surprised if this hasn't been already discussed in the lists as well), 
:the proper way to fix this problem is to separate the kernel and
:userland structures of ipfw, and add versioning to the struct.
:
:This can be done without even breaking the ABI again, since several
:pointers in the kernel structures are useless to userland (like the next
:field) and can be reused to implement structure versioning.
:
:Cheers,
:Maxime

If/when Luigi fixes the ABI problems with IPFW, we can remove
this 'hack'.  Until then, I do not consider the hackiness nature
of the patch sufficient reason to not put it in.  I've been bitten
by this problem dozens of times, and wasted many hours simply because
I couldn't get the damn network working, and so have others.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-14 Thread Sam Leffler
 :Now I would really dislike seeing your patch in the tree, since I
 :consider it's a rather crude hack to circumvent the ABI problems of
 :ipfw.  As I've already said to luigi in private e-mail (I would be
 :surprised if this hasn't been already discussed in the lists as well),
 :the proper way to fix this problem is to separate the kernel and
 :userland structures of ipfw, and add versioning to the struct.
 :
 :This can be done without even breaking the ABI again, since several
 :pointers in the kernel structures are useless to userland (like the next
 :field) and can be reused to implement structure versioning.
 :
 :Cheers,
 :Maxime

 If/when Luigi fixes the ABI problems with IPFW, we can remove
 this 'hack'.  Until then, I do not consider the hackiness nature
 of the patch sufficient reason to not put it in.  I've been bitten
 by this problem dozens of times, and wasted many hours simply because
 I couldn't get the damn network working, and so have others.

I disagree with committing this hack; keep it as a local mod if you must.

As to the problem; don't wait for Luigi to fix the ABI problems, do it
yourself.  Good things happen when folks are PO'd and won't settle for the
status quo.

Sam


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ipfw userland breaks again.

2002-12-14 Thread Matthew Dillon
:I disagree with committing this hack; keep it as a local mod if you must.
:
:As to the problem; don't wait for Luigi to fix the ABI problems, do it
:yourself.  Good things happen when folks are PO'd and won't settle for the
:status quo.
:
:Sam

I'm sorry you disagree, but it doesn't change my position.  I am not
in the business of rewriting other people's APIs.  If it means so much
to you, YOU go and fix it.  No?  Then don't complain about my fix.  It's
no skin off your nose and it will prevent a lot of future headaches,
especially if the RC system makes it nice and friendly.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message