On 10/3/06, Peter Allgeyer <[EMAIL PROTECTED]> wrote:
No, as I told you already, the system_start_ftp_helpers() is launched
_after_ filter_configure_sync in /etc/rc.bootup. And ftpsesame is killed
by "killall" in system_start_ftp_helpers() after been started in
filter_configure_sync :-( So, you can see, that the
afterfilterchangeshellcmd command isn't any solution for that problem.
When I'm posting lines of source code, you can believe me that I have
bravely taken a look at it ;-)
I wonder if the package system is called far enough into the boot
process to shim this in after start_ftp_helpers is called. You might
be able to create a start script that calls /etc/rc.filter_configure.
Looks like this is what you want in /etc/rc.bootup
mwexec("sh /usr/local/etc/rc.d/{$filename} start >>/tmp/bootup_messages 2>&1");
it's well past the ftp_helpers.
OK, I'll write my own code, since I'm experienced enough. I wanted a
clean solution for all users, but that's apparently not the goal here.
People will further cry at the forum that ftp isn't working. I do know
the reason why and now you know too.
Yeah, 1.0 is too close, we can't afford to break FTP for this somewhat
edge case. Hopefully we can come up with a better long term solution.
BTW: I do love the way the netfilter connection tracking modules in
linux are solving that problem and don't know any reason why that code
isn't adapted by the pf devs. There must be any reason for not using
such an API. I'll have to search why. Maybe you can give me a link.
There's plenty of discussions on this, I don't have any links handy,
sorry. But it goes along the lines of layer7 protocol analysis in
kernel is a bad idea - protocol bugs directly result in ring0
compromise (bad!). Using divert() style sockets is moderately better,
but results in dropping the analysis and throughput to userland which
can be slow. ftpsesame is a better compromise in that all it really
needs to do is run a bpf listener and add/remove rules as needed.
Some protocols (pptp, ipsec), etc, can only be NAT'd in kernel due to
the way the protocols work, but in those cases, it's not a rule issue,
it's a NAT issue that can't be solved outside of the kernel. IPFilter
has various "proxy" modules to handle some of this. At the end of the
day, the linux folks are more open to polluting their kernel with junk
than the OpenBSD folks.
--Bill
