Home/ Questions/Q 6768955
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T15:08:07+00:00

I am an integration consultant and tend to use C and Lua in my

  • 0

I am an integration consultant and tend to use C and Lua in my spare time, unfortunately it is not my day job ;-(

Anyway, I tend to believe that a mixture of C and Lua is perfect for many “product” developments. I currently have an “adapter engine” built in pure C, but would like to actually move the adapter code to Lua….

For example, coding an EMAIL adapter in Lua is far easier than in C…yet I like the “engine speed of C”….

But now there is the big question of security risk in that the user can potentially add whatever he or she wants to the LUa scripts in production…..obviously there we could CHMOD the files…but is that really secure?

Ideally I want the C / Lua combination here….but now do I literally imbed the Lua code in the C application with a CHAR*….or do I issue a lua_dofile??

Thanks for the help

Lynton

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    First, one of the drawbacks to using C/Lua in production is it tends to be harder to find resources who can develop for these languages. C++ and JavaScript programmers are typically easier to find.

    In terms of security, the key here is to use leading practices. Security is about risk reduction, there is no expectation one can achieve perfect security so you need to mitigate risk.

    Here are my suggestions:

    • As with all middleware you need to use a hardened server. This is the first step, if the server is compromised using any platform you are in trouble. Middleware should NOT be in the DMZ.

    • You want to store the Lua code external to the compiled code (otherwise you lose the advantage of using Lua.) Make that storage as secure as you can. CHMOD is good, a secure DB server is better. The more secure the script store the more secure the system.

    • You can encrypt the Lua source – this is a trade off since it makes it a little harder to gain the advantage of easy updates and modification. You will probably need to implement decrypted script caching for performance.

    • Your security is as strong as your weakest link. If you provide a way to modify the Lua source via external access this will be an attack vector. Avoid this design if you can.

    • You should consider putting in change management checks. For example a separate place in the system where a checksum for each Lua file is stored. Then if an un-authorized change is made to a script you can abort functioning till the security breach is mitigated.

    Other than the drawback I mentioned above, I don’t think there is anything fundamentally flawed in your plan. If it can aid in making a good middleware system I would say go for it. Just mitigate the risk of your adapter scripts getting compromised as much as possible.

    To expand on Donal’s comment – given the popularity of node I would say that JavaScript is the the leading practice in scripted middleware right now. If you can handle learning a new scripting language I would say it would be a good idea given the support, popularity, and tools available.

    • 0