None of the binaries are setuid/setgid, so there's no risk of running code
at a privilege level different than any other code that the logged-in user
is allowed to run.
You do make a good point that a sysadmin should be aware of -- a user
could install a "trojan module" which provides entry points for the
functions that the dbmail-*'s expect, but runs nefarious code. A sysadmin
should not, then, 'cd ~eviluser ; dbmail-lalala' because you might get
hosed.
Aaron
On Thu, Dec 14, 2006, Bernard Johnson
<[EMAIL PROTECTED]> said:
> 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
>
--
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
