Re: [AD] al_set_win_dll_path

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 2011-07-27, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> On Wed, Jul 27, 2011 at 5:13 AM, Elias Pschernig
> <elias.pschernig@xxxxxxxxxx> wrote:
> > al_set_standard_path(int id, ALLEGRO_PATH *path)?
> >
> I thought about recommending that before when we had the long
> discussions. Maybe I did, I dunno.
> 
> It's probably only useful with ALLEGRO_RESOURCES_PATH, but ultimately
> I think I decided that the programmer might as well just create a
> wrapper function like get_path() around ALLEGRO_RESOURCES_PATH and his
> own UNIX_CONFIGURE_DATA_PATH compile time option.
> 
> Anyway, all that is kind of a side topic. But maybe there is something here.
> 
> There could be something like ALLEGRO_LIBRARY_PATH that is writable,
> but you'd almost have to then add support for multiple paths for a
> single id, via al_get_nth_standard_path(int id, int n).
> 
> I think I would prefer the following:
> 
> * roll back the change to Windows that prevents DLL hijacking. Does it
> really matter?

I think so.  Most likely there aren't any Allegro-based programs which
are popular enough for any malware authors to target, but it's not
outside the realm of possibility.

> 
> * set the PATH/LD_LIBRARY_PATH environment variable yourself, and let
> Allegro automatically pick that up.

The main problem is loading DLLs from the _current_ directory, so it
should be relatively safe to load from the PATH (excluding the current
directory).  I can't remember why I didn't implement that; possibly
because it requires more work.

> If you don't want to disable the DLL hijack completely, you could do
> something like:
> 
> c = al_get_system_config();
> al_set_config_value(c, "windows", "use_sys_path_for_dlls", "1");
> 
> And failing that suggestion:
> 
> c = al_get_system_config();
> al_set_config_value(c, "path", "library", "c:/foo/bar");
> 
> And failing that suggestion:
> 
> al_set_plugin_search_path(ALLEGRO_PATH *path)

I liked the suggestion for setting the exename explicitly.
Presumably the Python wrapper could set that to
the user's game.py, and DLLs could be placed next to that.

Peter




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/