Re: Discover default package.path, package.cpath?

[Sean Conner <sean@...>]

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
> special.

  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 ... )