This function returns a list of <module dir, data dir> pairs which lists all
places in which modules should be looked for.
FindModPath() and GetAvailableMods() are changed to use this new function.
The list of places to look at is the same that was used before, but this now
also adds ./modules/extra so that modules enabled via --enable-extra are found
before 'make install'.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1612 726aef4b-f618-498e-8847-2d620e286838
Instead of using sed to strip away the source dir this now uses make's notdir.
$(notdir this/is/an/example) results in example.
This also moved the generated dependency files from .depend/extra into .depend/
Since we need the extra/ path prefix for the modules from modules/extra, that
one is added back via addprefix.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1610 726aef4b-f618-498e-8847-2d620e286838
The configure and Makefile stuff was taken from there, too. By default modtcl is
disabled, use --enable-extra --enable-tcl to get it.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1609 726aef4b-f618-498e-8847-2d620e286838
This commits adds the necessary build system fun for extra modules in
modules/extra which can be enabled with --enable-extra.
This is a preparation for the import of znc-extra.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1605 726aef4b-f618-498e-8847-2d620e286838
Thanks to Sickness for reporting this and providing backtraces and for flakes
for writing a first patch that Sickness tested.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1603 726aef4b-f618-498e-8847-2d620e286838
Now ZNC doesn't try to join the first, then the second etc channel, but instead
it will start at a random channel and go on from there.
This fixes a bug if you got e.g. MaxJoins = 5 and your first five channels are
invite-only. Without this, ZNC would never try to join any of the other
channels. With this patch applied, it will sooner or later try to join the other
channels, too. (I'd guess more sooner than later)
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1602 726aef4b-f618-498e-8847-2d620e286838
/lusers can cause a 250 "Highest connection count" reply, but sadly some IRC
daemons don't send this numeric. Since there is no easy way to handle this, we
will just assume that 266 is the last numeric reply to /lusers.
*If* there is a 250 reply, it will be broadcasted to all connected clients. This
is still better than the "This module hit a timeout" we generate on some ircds
currently.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1600 726aef4b-f618-498e-8847-2d620e286838
This teaches route_replies how to parse 461 numerics to find out which command
caused them. This way we don't have to add this numeric to all the requests we
route by hand.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1598 726aef4b-f618-498e-8847-2d620e286838
The old code first tried to dlopen() the module again to find out if it's a
global or a user module. This could have lots of weird effects.
Now we just unload the user module and if that fails retry with the global
module (if the user got the appropriate privileges).
This removes and fixes the #warning added in the last commit.
P.S.: Oh and this is less LOCs now!
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1597 726aef4b-f618-498e-8847-2d620e286838
Ever since r1505 our error messages when loading modules all were the same:
"Unable to find modinfo"
Improve this by giving the user all the information we offered before again. The
most useful one here is most likely the result from dlerror(). This is done by
adding a helper function CModules::OpenModule(). Most of its code is from
CModules::LoadModule() and this function and CModules::GetModInfo() now both use
this helper function for generating error messages.
This commit adds a "#warning", don't worry I'm working on it.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1596 726aef4b-f618-498e-8847-2d620e286838
This module logs events like failed and successful logins and IRC disconnects to
a log file and/or syslog.
Original module author is SilverLeo, thanks.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1595 726aef4b-f618-498e-8847-2d620e286838
This module fixes some issues if multiple clients are connected to the same ZNC
user. ZNC itself would send replies to e.g. /who to all connected clients and
this modules makes the reply go to the client which sent the request.
Thanks to SilverLeo, tomaw and Vadtec for finding missing numerics.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1594 726aef4b-f618-498e-8847-2d620e286838
This module automatically replies to queries and private notices if no user is
connected to ZNC.
Svedrin submitted an initial version of this module, but due to my own
stupidness I later rewrote it.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1593 726aef4b-f618-498e-8847-2d620e286838
This module adds topic changes, nick changes, parts, joins, quits, kicks and
mode changes to the buffer playback.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1592 726aef4b-f618-498e-8847-2d620e286838
CSocket sometimes calls our select() wrapper with writeds == NULL and we didn't
handle this case at all which lead to a NULL pointer dereference.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1586 726aef4b-f618-498e-8847-2d620e286838
The source of commands is supposed to be a complete nick mask, but we only used
the nick.
Thanks to flakes for (kinda) noticing this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1584 726aef4b-f618-498e-8847-2d620e286838
Without this we could cause a client desync (ZNC still got the correct
information).
Bug reported by tomaw and patch provided by flakes, thanks.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1583 726aef4b-f618-498e-8847-2d620e286838
autoconf automatically substitutes @PACKAGE_VERSION@, so there is not much point
into adding another substitute for this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1582 726aef4b-f618-498e-8847-2d620e286838
- The last commit broke windows (= everything which uses libznc)
(sorry, copy&paste error)
- distclean left the .pc files behind
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1581 726aef4b-f618-498e-8847-2d620e286838
/version generates a 005 server reply. We used to cache this reply in the raw
buffer and the next user who logs in then received the same 005 reply multiple
times.
We fix this by adding CBuffer::UpdateExactLine() which does nothing if the exact
same line is already in the buffer. The only place where we (currently?) use
this is the raw 005 reply.
This should fix sf bug #2817124.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1579 726aef4b-f618-498e-8847-2d620e286838
When a user is deleted we didn't properly clean up after it. Active DCC
connections (CDCCBounce and CDCCSock) where left laying around and at some later
point of time they used their CUser* pointer which now pointed to invalid data.
This bug is similar to the one from r1557.
Thanks to cnu, our beloved master of destruction, for finding yet another way to
make ZNC break and for testing the patch.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1575 726aef4b-f618-498e-8847-2d620e286838
The directory prefix checking which prevents path traversal exploits had a logic
error that made it always fail.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1574 726aef4b-f618-498e-8847-2d620e286838
You can upload files to znc via /dcc send *status. The files will be saved in
<datadir>/users/<user>/downloads/. The code for this didn't do any checking on
the file name at all and thus allowed directory traversal attacks by all znc
users (no admin privileges required!).
By exploiting this bug, attackers could e.g. upload a new ssh authorized_keys
file or upload a znc module which lets everyone gain shell access. Anything is
possible.
Again:
ONLY A NORMAL USER ACCOUNT NEEDED, no admin privileges.
THE ATTACKER GOT WRITE ACCESS TO ALL PLACES ZNC GOT WRITE ACCESS TO.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1570 726aef4b-f618-498e-8847-2d620e286838
A common pattern for checking directories in ZNC is the following:
sAbsolutePath = CDir::ChangeDir(sAllowedPath, sFile);
if (sAbsolutePath.Left(sAllowedPath.length()) != sAllowedPath)
Error;
But there is a problem: If sAllowedPath doesn't end with a slash, we are
vulnerable to an attack. If e.g. sAllowedPath = "/foo/bar", then
sFile = "../bartender" would result in sAbsolutePath = "/foo/bartender". Since
this path does begin with sAllowedPath, the code allowed it.
There shouldn't be any places where this can be exploited currently, but it is
still a security bug (path traversal).
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1569 726aef4b-f618-498e-8847-2d620e286838
The issue happened if off_t was a signed, 4 byte integer (x86). In this case
(off_t) 0xffffffff is -1 and a file size is always larger than -1 which
unconditionally caused the "File too large" error to trigger.
Thanks to [Deton8r] for reporting this bug and flakes for debugging it.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1568 726aef4b-f618-498e-8847-2d620e286838
This now states more explicitly that c-ares is not strictly required.
Thanks to flakes for noticing that the error messages needs improvement and to
w00t for improving the improved error message flakes and me came up with.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1565 726aef4b-f618-498e-8847-2d620e286838
Everything which isn't a CClient with a successful login counts as an
unidentified connection in this context. Modules who don't want this kind of
limit on their listening sockets can override CSocket::ConnectionFrom(), but
their sockets will still count towards this limit.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1561 726aef4b-f618-498e-8847-2d620e286838
