permissions for Lua Scripts in C - linux

Is it possible to give the lua script lower permissions so that it is not possible to execute OS functions ?
for example:
os.execute("mkdir ..")
I use the lua 5.3.5 library. Maybe it includes an option to allow or disallow some lua functions?

Yes it is possible, typically Lua initialization load all the standard library:
lua_State *LuaState = luaL_newstate();
luaL_openlibs(LuaState);
But you could adjust to include just what you need with the functions from lualib.h:
luaopen_package
luaopen_coroutine
luaopen_string
luaopen_utf8
luaopen_table
luaopen_math
luaopen_io
luaopen_os
luaopen_debug
In such case you could have the following initialization:
lua_State *LuaState = luaL_newstate();
luaopen_io(LuaState);
luaopen_table(LuaState);
luaopen_string(LuaState);
You can find more details in the chapter 6 of the documentation
http://www.lua.org/manual/5.3/manual.html#6

If you use luaL_openlibs to load Lua's standard libraries, just copy linit.c to your project and edit it to choose the libraries you want to export.
If you want to remove only a few functions, do this after loading the libraries:
luaL_dostring(L,"os.execute=nil");

Related

When a shared library is loaded, is it possible that it references something in the current binary?

Say I have a binary server, and when it's compiled, it's linked from server.c, static_lib.a, and dynamically with dynamic_lib.so.
When server is executed and it loads dynamic_lib.so dynamically, but on the code path, dynamic_lib.so actually expects some symbols from static_lib.a. What I'm seeing is that, dynamic_lib.so pulls in static_lib.so so essentially I have two static_lib in memory.
Let's assume there's no way we can change dynamic_lib.so, because it's a 3rd-party library.
My question is, is it possible to make dynamic_lib.so or ld itself search the current binary first, or even not search for it in ld's path, just use the binary's symbol, or abort.
I tried to find some related docs about it, but it's not easy for noobs about linkers like me :-)
You can not change library to not load static_lib.so but you can trick it to use static_lib.a instead.
By default ld does not export any symbols from executables but you can change this via -rdynamic. This option is quite crude as it exports all static symbols so for finer-grained control you can use -Wl,--dynamic-list (see example use in Clang sources).

Linux library code injection & calls to identically named functions in SOs

I have built a linux shared object which I inject into a 3rd party program to intercept some dynamic function calls using LD_PRELOAD.
The 3rd party program uses a SO "libabc.so" located at some path. My injected SO uses another SO, also called "libabc.so" located at another path (essentially identical but slight code differences).
My problem is now, that calls to a function "def" which appear in both libabc.so are always resolved by the first. (Presumably because it is loaded first?!) How can I get them to be resolved with the second libabc.so?
Many thanks!
Unless something changed since I used to do this, you will need to dlopen() the library you want to pass calls on to and call the function manually, something like;
handle = dlopen("/path/to/libabc.so", RTLD_LAZY);
otherDef = dlsym(handle, "def");
orderDef(parameter);
There is a complete example how to do this very thing at LinuxJournal.
If you only want to use one libabc.so version, you can always use LD_PRELOAD to load it along with your own shared object before anything else.
If you want to use multiple versions, you have a few alternatives:
Use dlopen() in your shared object to load that library. Since you have created a function injection object you should be familiar with this procedure. This is the more generic and powerful way - you could even mix & match functions from different library versions.
Use a different DT_SONAME for the library version your shared object links against. Unfortunately this requires (slightly) changing the build system of that library and recompiling.
Link your shared object statically against the library in question. Not always possible but it does not require modifying the library in question. The main issue with this alternative is that any change in the library should be followed by a relinking of your shared object for the changes to be pulled in.
Warning: you may need to use a custom linker script or specific linker options to avoid symbol conflicts.

Create both static and shared library with GNU libtool?

I am using the GNU autotools (including automake!) for my project. I would like to know if I could create a static and a shared library using libtool? Or would the declarations be separate? Would this:
LT_INIT(shared static)
work?
Nothing besides LT_INIT is needed, it defaults to building both static and shared libraries. If you like, you can again explicitly state the defaults (but it is sort of redundant)
LT_INIT
AC_ENABLE_SHARED
AC_ENABLE_STATIC
edit: manual says LT_INIT([shared]) and LT_INIT([static]) (combined to LT_INIT([shared static]) shall also work. Also manual's more precise wording on what's default when LT_INIT is given:
this macro turns on shared libraries if they are
available, and also enables static libraries if they don't
conflict with the shared libraries.

How to check Shared Library exposed functions in program

I am using a third party shared library and I need to check whether a function is exported by shared library programatically.
How to do this. I need this because if function does not exist I need to run some other function locally.
You could probably use dlsym for this.
If you load the library with dlopen, you will use the handle that it returns.
If you're linked against this library you may use special pseudo-handles (10x to caf for pointing it out):
From dlsym man:
There are two special pseudo-handles, RTLD_DEFAULT and RTLD_NEXT. The former will find the first occurrence of the desired symbol using the default library search order. The latter will find the next occurrence of a function in the search order after the current library. This allows one to provide a wrapper around a function in another shared library.
Check the header file of the intended library to get the function signature.
Using dlopen you can load the library dynamically and fetch the symbol if it is exposed in the library with subsequent calls to dlsym and dlclose.
may be you can use objdump command to check all symbol exposed like this
objdump -T libtest.so

Automake and standard shared libraries

How can I force automake to create a standard shared library, instead of a libtoolized one? Normally, I'd create the abc.so which is referenced with a full path and loaded into the main program. Is there a way to force AM to do the same? If I list it as _LIBRARY, automake complains: 'abc.so' is not a standard library name; did you mean 'libabc.a'
Just to clarify: Yes, I only need .so support - no statics. And yes, I want a custom file name.
libtool is the way to go. If you want a custom name, add the -module option to _LDFLAGS, for example:
plugindir= /some/where
plugin_LTLIBRARIES= abc.la
abc_la_LDFLAGS= -module
Automake does not know how to build a shared library because there is no portable way to do so. If you want a shared library with Automake, you have to use Automake+Libtool. Note that you can easily configure libtool not to build any static library (with LT_INIT([disable-static]) in your configure.ac) by default.
A libtoolized library is a wrapper around one or more standard libraries.
You can find these libraries in ".libs" after running "make", or in "$prefix/lib" after running "make install".
On a Linux machine, you should find eventually a file called "libabc.so".
IIRC, there is nothing special about libraries created with the help of libtool, unless you link against libltdl. If you do not want to use libtool, you have the power to choose and do not care too much about portability, then you are free to use automake without libtool. I would recommend to use the power of libtool instead.
Actually, I do not even know what _LIBRARY is good for, did not found it in the the manual/Linking section.

Resources