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
We need to have an upper limit of the size of HTTP POST data. With the current
code you could just send 4 GiB of data to webadmin and ZNC would try to keep all
of this in memory.
This patch implements an upper limit for HTTP POST data of 1 MiB.
Thanks to cnu for finding this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1559 726aef4b-f618-498e-8847-2d620e286838
If a user is deleted while it is trying to connect to an IRC server, the IRC
socket wasn't deleted together with the user. At some later point in time, the
IRC socket will try to use the user object, which was already freed by now.
Fix this by erasing IRC sockets together with their user object.
Thanks to cnu for reporting this.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1557 726aef4b-f618-498e-8847-2d620e286838
After the first attempt to lookup an address, Csocket already created the socket
used for communicating. Since at this point it wasn't yet known whether we will
yield a IPv4 or IPv6 address, Csocket just always used IPv4. This would then
later fail to connect() with 'Address family not supported by protocol'.
This patch fixes this by creating the socket fd only when the DNS lookup
completed successfully.
git-svn-id: https://znc.svn.sourceforge.net/svnroot/znc/trunk@1556 726aef4b-f618-498e-8847-2d620e286838
