Hi folks, I'm currently working on our libwrap support in inetd. Working with the originators of a few PR's, I've come up with a diff that gets most of what we need right, including the severity option of hosts_options.
I'm taking on hosts_options' twist now. The problem with twist is that it execl()'s, which isn't at all cool for the listening inetd (it's not a problem for forked inetd processes). I've put something together that teaches tcp_wrappers' hosts_access() to allow the caller to frob a flag called fork_on_twist. If the flag is set, twist_option() (the function that does the execl) will fo a fork before the execl, with the child doing the execl and the parent failing hosts_access. It suddenly occured to me while I was testing this that I might be going to a lot of trouble under the misguided assumption that a fork is expensive. Am I wrong? Inetd already forks for some internal services and for all external services, so the only extra forks would be for a few of the internal services. Would there be a noticeable impact on inetd's if it _always_ forked before calling hosts_access()? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
