[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Discover default package.path, package.cpath?
- From: Sean Conner <sean@...>
- Date: Thu, 3 Jan 2019 18:03:46 -0500
It was thus said that the Great Norman Ramsey once stated:
> > It was thus said that the Great Norman Ramsey once stated:
> > > From within a Lua process that has already launched, is there a way to
> > > discover the *default* paths, especially package.cpath?
> > >
> > > Context: I have to treat the LUA_CPATH environment variable as if it
> > > were controlled by an adversary, and I do not have the ability to
> > > launch Lua with the -E option. My choices will be either to put some
> > > kind of wrapper around my Lua binary or to launch a separate process
> > > to determine the default path. Neither of these choices is ideal.
> > >
> > > A solution for 5.1 would be perfect, but if it's doable even using a
> > > later version, I might be able to retrofit.
> > First, what is your thread model? Is it *just* LUA_CPATH and not
> > LUA_PATH? Or LUA_INIT? If it's just to prevent an adversary from loading a
> > custom version of a C-based module, all they need to do is call
> > package.loadlib() directly to load a C-based module.
> Oy. I need to protect LUA_PATH as well (and LUA_PATH_5_x, and ...).
> I overlooked LUA_INIT. I need to do something like that as well.
Don't forget package.loadlib().
> > Second, is modifying Lua an option?
> No. It's running on an installation that I don't administer, and on
> the whole, I think I'd rather pay an extra dynamic cost on every run,
> rather than rely on all future administrators to preserve something
You could always wrap the invokation of lua in a shell script that
modifies the environment (by removing $LUA_*) and then execs the actual lua
executable but I find it odd that you can't run lua with the '-E' option.
Is your threat model the actual system administrators? Just how would an
adversary get control?
-spc (Kind of confused here ... )