phil at pricom
Nov 18, 2009, 8:58 AM
Post #17 of 17
(2997 views)
Permalink
|
Markus, Kyle, Otavio,
On 2009-11-19 03:05, Kyle Wheeler wrote:
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>
> On Wednesday, November 18 at 03:47 PM, quoth Philip Rhoades:
>> Yes, I understand and it is more or less what I thought - so if
>> greylite (or any other prog in the chain) exits with the
>> appropriate return value, the rest of the chain is not executed?
>
> If you're worried about the return value, then you're not
> understanding what I wrote.
>
> The process is called "exec chaining" because the fundamental aspect
> of it is the "exec" system call, which (on Unix machines) fully and
> completely replaces the application that makes the call with the
> program it specifies. For example, if I have a program (let's call it
> "tcpserver") that calls "exec(/usr/bin/greylite)", then the program
> is no longer tcpserver, it is now greylite. Tcpserver is gone and
> cannot come back, it cannot control what greylite does, and when
> greylite exits the program simply ends (tcpserver does not restart
> or come back or anything even remotely similar). An "exec chain" is
> when several programs exec each other one after the next: first
> tcpserver execs greylite, then greylite execs qmail-smtpd, then
> qmail-smtpd exits, the end. (OR, alternately, first tcpserver execs
> greylite, then greylite exits, the end.) You see? The "return code"
> has no impact on the chain. In fact, when a program calls "exec", it
> does not have an opportunity to return any code of any sort: it is
> now a completely different program.
Right.
> Now, things are actually slightly more complicated. The "exec" call
> is normally (i.e. when not doing "exec chaining") paired with a
> "fork" call. "Fork", on Unix machines, creates a duplicate of a
> program. So, if tcpserver calls "fork", suddenly I have *TWO*
> instances of tcpserver. This is how tcpserver can behave as a
> server. For every new connection, it duplicates itself. The original
> goes back to listening for new connections, while the duplicate
> calls "exec" to replace itself with some program (e.g. greylite).
>
> Thus, tcpserver runs one program, and only one program, and only ever
> one program.
Right.
> That program may do whatever it likes. It can exec another program
> (and thus cease to exist), OR it may return whatever return code it
> likes. Tcpserver (the original) does nothing more than record that
> return value in the log file.
>
> Does that clear things up somewhat?
Very well thanks!
>> So if I construct a script that does the filtering that I want then
>> I just need it to be able to exec the rest of the chain if
>> necessary?
>
> Exactly.
>
> For example, if you wanted to create a script that would only allow
> connections from the IP address 1.2.3.4, what would that mean? (Yes,
> there are simpler ways of doing this than with a wrapper script, but
> I'm using this as an informative example.) In an exec-chain like
> this, "allowing the connection" means "continuing the chain", which
> really means "exec-ing the next program in the chain (and passing
> along the arguments to define the rest of the chain)". "Denying the
> connection" means simply exiting.
>
> So, here's an example simple script that demonstrates (more verbosely
> than necessary) the idea:
>
> #!/bin/bash if [ $TCPREMOTEIP == 1.2.3.4 ] ; then exec "$@" else
> exit $RANDOM fi
>
> You'll notice that the exit code is random. That's to emphasize that
> it is irrelevant. You may be wondering "what does this "$@" mean?".
> In bash, the $@ variable is a reference to the arguments that have
> been passed to the program. Putting the $@ variable in quotes tells
> bash to expand the variable to its component pieces as if each
> component (each argument) was in quotes (if that makes no sense to
> you, ignore it for the moment and just take on faith that the quotes
> are important to use).
OK.
> So, now you have to ask yourself: how does this fit into the chain?
> You'll note that it doesn't check the return value of whatever it
> exec's, and yet the exec chain after this program can be long and
> complicated.
>
> If you already know all this, I apologize for flogging a dead horse.
> But by talking about the return code, it sounded like you didn't
> quite understand the concept.
No, I was probably still a bit confused and I didn't explain myself
clearly enough - I guess I was thinking of the qmail-qfilter situation
and the return codes from the filter programs returned to the
qmail-qfilter program.
> It's worth pointing out: this is VERY different from how
> qmail-qfilter works, because qmail-qfilter doesn't use exec
> chaining. Qmail-qfilter runs each program (read: "filter"), captures
> its output and its return code, and decides whether to run the next
> program.
Understood clearly now.
> ~Kyle
Many thanks for the in-depth responses! I have learnt a lot with this
exercise!
Appreciatively,
Phil.
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil [at] pricom
|
Emanuel.exe
