Re: Execution of signed scripts received by e-mail
-----BEGIN PGP SIGNED MESSAGE----- Hal <hfinney@shell.portal.com> writes:
That sounds very impressive! The one problem I've run into with mail filtering software is that each message asynchronously spawns a separate filter process. This can cause some conflicts with accessing disk files. I haven't used procmail so I don't know if it has this problem. But if so you may need to be careful if there are any cases where two processes could be accessing the same disk files. For example, what if two copies of an identical email message arrive at almost the same time, would your dup detection work.
If I am reading the procmail docs correctly, then the following recipe should create a lockfile called 'emscrypt.lock' which will prevent more than one instance of the script from being run at a time :0:emscrypt ^ Subject.*SQUEAMISH OSSIFRAGE |/PATH/emscrypt I agree it would be better if emscrypt used its own locks on the timestamp files. However, it is my understanding (someone please correct me if I am wrong) that there is no simple way to provide file locking in Perl that is portable across the various flavours of Unix (see the descriptions of the fcntl and flock functions on p. 144-145 of the Camel book). So I haven't tried to implement locking from within emscrypt yet. Of course, if these functions are available on the majority of machines (anyone?) then I should probably use them.
The other issue is the possibility of mail arriving out of order. Looking for increasing timestamps may cause spurious rejection of some messages. On the other hand this is a difficult problem to handle in general so probably the current solution is OK.
Yeah, I though about that too. It can be somewhat alleviated by batching the individually signed scripts into a single mail message, if you know you are going to be submitting several scripts close together in time. Any other ideas?
Hal
Thanks for the feedback. - --Matt - -- mcarpent@mailhost.tcs.tulane.edu -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMejLIijtJAMyBnp9AQHnYgf6AkCfu7KLGKmJ6JNe0JscYkqWwHWGStFW 0u0dMrQekySy75iRqvyHJ789BhUj2gH5DhKBK97C0AhKj2jmv//7RALadqXOa73G 9nF31evxd+IItWaxeWbQQT9yNvEOz/bmLrz0bgH+GEwKHRFmUmwOObo4bw59M2bc EianNNT0Ig4tOcVt6kaxWm79PylQvDvtIxy6e3g0wIyg0gUI9vzGSa7S1y9PAJSB d60yJAfYKSEPGoab8fDbrTbJLMUfR1BYevdHrJxxCiuOj9uhIEfCnHua/P6k6tvP ZIa8Bz3jilq+AE/+CzBezk0IJmq7MEMQFJHyk/1AtKwY58x6xxWxuQ== =S64i -----END PGP SIGNATURE-----
Matt Carpenter wrote: | If I am reading the procmail docs correctly, then the following recipe | should create a lockfile called 'emscrypt.lock' which will prevent more than | one instance of the script from being run at a time | | :0:emscrypt | ^ Subject.*SQUEAMISH OSSIFRAGE | |/PATH/emscrypt | | I agree it would be better if emscrypt used its own locks on the timestamp | files. However, it is my understanding (someone please correct me if I am | wrong) that there is no simple way to provide file locking in Perl that is | portable across the various flavours of Unix (see the descriptions of the | fcntl and flock functions on p. 144-145 of the Camel book). So I haven't | tried to implement locking from within emscrypt yet. Of course, if these | functions are available on the majority of machines (anyone?) then I should | probably use them. procmail includes a program called lockfile, which is based on its thorough as hell lock mechanism tests. If you're calling from procmail, you might decide to require lockfile. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
"Matt" == Matt Carpenter <mcarpent@Dusk.obscure.net> writes: "Hal" == Hal <hfinney@shell.portal.com> writes:
Hal> That sounds very impressive! The one problem I've run into with Hal> mail filtering software is that each message asynchronously Hal> spawns a separate filter process. This can cause some conflicts Hal> with accessing disk files. Matt> If I am reading the procmail docs correctly, then the following Matt> recipe should create a lockfile called 'emscrypt.lock' which Matt> will prevent more than one instance of the script from being run Matt> at a time Matt> :0:emscrypt Matt> ^ Subject.*SQUEAMISH OSSIFRAGE Matt> |/PATH/emscrypt That is half correct. It will only create emscrypt.lock if you have configured procmail for that kind of locking, otherwise it will use lockf or flock to make the lock. As Hal pointed out, you will still have one process per message, but they will be processed one at a time. Matt> I agree it would be better if emscrypt used its own locks on the Matt> timestamp files. However, it is my understanding (someone Matt> please correct me if I am wrong) that there is no simple way to Matt> provide file locking in Perl that is portable across the various Matt> flavours of Unix (see the descriptions of the fcntl and flock Matt> functions on p. 144-145 of the Camel book). Another possibility is to call lockfile (a program included with procmail which performs compatible locking). You're better off using procmail's locking as it does what you're looking for, and many people have beat on the code over the years. -- steve@miranova.com baur Unsolicited commercial e-mail will be proofread for $250/hour. Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone except you in November.
participants (3)
-
Adam Shostack -
Matt Carpenter -
Steven L Baur