The *only* reason for inclusion of "modules/.libs" is facilitating
developement. It could easily be (de)activated with an #ifdef.
Bernard Johnson wrote:
> Isn't it a little of a security concern that dbmail-* loads code from
> relative paths? I guess that I wouldn't be too concerned about imapd,
> pop3d, lmtpd, or timsieved, since I more or less never run them except
> via init scripts, so the working directory is set everytime.
>
> But for something like dbmail-util or dbmail-users, what if someone
> managed to plant a .so in the current working directory or in
> modules/.libs under the current working directory.
>
> Since NULL is the last to be searched, I guess it's not too much of a
> concern either, since I expect to always have PREFIX/lib/dbmail
> installed if I'm running these utilities.
>
> But what about the possibility of loading from modules/.libs???
>
> File: dbmodule.c
> /* Try local build area, then dbmail lib paths, then system lib path. */
> int i;
> char *lib_path[] = {
> "modules/.libs",
> PREFIX "/lib/dbmail",
> NULL };
> /* Note that the limit here *includes* the NULL. This is intentional,
> * to allow g_module_build_path to try the current working directory. */
>
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
