Re: [vchkpw] Vusaged segmentation fault on long names

2009-09-10 Thread Wouter van der Schagt

I will be releasing a better fix shortly.


My apologies for the late reply, I was busy moving.

I can confirm that the newly released version no longer contains this bug 
and have updated all servers to the latest 5.4.28 version. Thanks for the 
fix!


Sincerely,
- Wouter van der Schagt 



!DSPAM:4aa9251c32712038326845!



[vchkpw] Vusaged segmentation fault on long names

2009-09-02 Thread Wouter van der Schagt

Hi all,

I found a bug with long domain names which crashes with a segmentation fault 
when the vusaged is started. We have 1 client with a domainname of 57 
characters and although it is not the domain name listed below, it produces 
the same result. I believe vpopmail supports domainnames upto 63 characters? 
Or am I wrong?


Steps to reproduce:

/home/vpopmail/bin/vadddomain -e postmaster 
12345678901234567890123456789012345678901234567890123456.nl test

/home/vpopmail/bin/vusaged

Returns a segmentation fault:

config: using /home/vpopmail/etc/vusaged.conf
socket: listening on /tmp/vusaged.sock
controller: stage one
Segmentation fault

Running through gdb results in:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb2bb9b90 (LWP 29861)]
0xb7e656c1 in mysql_free_result () from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0xb7e656c1 in mysql_free_result () from /usr/lib/libmysqlclient.so.15
#1  0x08059079 in vauth_getall (domain=0x8066afe 
12345678901234567890123456789012345678901234567890123456.nl, first=1,

   sortit=1) at vauth.c:737
#2  0x08051244 in queue_controller ()
#3  0xb7d644b5 in start_thread () from /lib/i686/cmov/libpthread.so.0
#4  0xb7ce0a5e in clone () from /lib/i686/cmov/libc.so.6
(gdb) bt full
#0  0xb7e656c1 in mysql_free_result () from /usr/lib/libmysqlclient.so.15
No symbol table info available.
#1  0x08059079 in vauth_getall (domain=0x8066afe 
12345678901234567890123456789012345678901234567890123456.nl, first=1,

   sortit=1) at vauth.c:737
   domstr = value optimized out
   err = value optimized out
   vpw = {pw_name = 0x8068f00 , pw_passwd = 0x8068e20 , pw_uid = 0, 
pw_gid = 8192, pw_flags = 8192,
 pw_gecos = 0x8068c60 , pw_dir = 0x8068b80 , pw_shell = 
0x8068d40 , pw_clear_passwd = 0x8068aa0 }

   more = 7106143
#2  0x08051244 in queue_controller ()
No locals.
#3  0xb7d644b5 in start_thread () from /lib/i686/cmov/libpthread.so.0
No symbol table info available.
#4  0xb7ce0a5e in clone () from /lib/i686/cmov/libc.so.6
No symbol table info available.

I am guessing that a buffer size is too small. Increasing the SQL_BUFF_SIZE 
in vauth.c to 4096 seems to work, to the extend it throws the same error 
message later:


[Switching to Thread 0x7134a950 (LWP 15136)]
0x77a5b5c5 in mysql_fetch_row () from /usr/lib/libmysqlclient.so.15
(gdb) bt full
#0  0x77a5b5c5 in mysql_fetch_row () from 
/usr/lib/libmysqlclient.so.15

No symbol table info available.
#1  0x004117d1 in vauth_getall (domain=0x62205e 
12345678901234567890123456789012345678901234567890123456.nl,

   first=value optimized out, sortit=1) at vauth.c:754
   domstr = 0x622700 
12345678901234567890123456789012345678901234567890123456_nl

   err = value optimized out
   vpw = {pw_name = 0x6259c0 , pw_passwd = 0x6258e0 , pw_uid = 0, 
pw_gid = 0, pw_flags = 0,
 pw_gecos = 0x625720 , pw_dir = 0x625640 , pw_shell = 0x625800 
, pw_clear_passwd = 0x625560 }

   more = 1
#2  0x0040a21a in queue_controller ()
No locals.
#3  0x76ee3f9a in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x76c5856d in clone () from /lib/libc.so.6
No symbol table info available.
#5  0x in ?? ()
No symbol table info available.

So I'm guessing more than 1 buffer size needs to be increased.

Sincerely,
- Wouter van der Schagt



!DSPAM:4a9e325232711452616560!



Re: [vchkpw] Vusaged segmentation fault on long names

2009-09-02 Thread Matt Brookings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Wouter van der Schagt wrote:
 I found a bug with long domain names which crashes with a segmentation
 fault when the vusaged is started. We have 1 client with a domainname of
 57 characters and although it is not the domain name listed below, it
 produces the same result. I believe vpopmail supports domainnames upto
 63 characters? Or am I wrong?

Is this in 5.5?  What are the steps to reproduce?  I added the domain as
you did above, and my vusaged binary from trunk is running as expected,
returning data for the long domain name.

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0xb2bb9b90 (LWP 29861)]
 0xb7e656c1 in mysql_free_result () from /usr/lib/libmysqlclient.so.15
 (gdb) bt
 #0  0xb7e656c1 in mysql_free_result () from /usr/lib/libmysqlclient.so.15
 #1  0x08059079 in vauth_getall (domain=0x8066afe
 12345678901234567890123456789012345678901234567890123456.nl, first=1,
sortit=1) at vauth.c:737

This would seem to indicate that the issue occurred somewhere in vpopmail's
vauth_getall call, or in MySQL itself.

Can you post your vusaged.conf, configure options for the main tree,
and configure options for the MySQL module?

 I am guessing that a buffer size is too small. Increasing the
 SQL_BUFF_SIZE in vauth.c to 4096 seems to work, to the extend it throws
 the same error message later:

I'm not sure the buffer size is really a problem here.  It's set at 2048, which
is plenty to handle even the longest domains and usernames.

Something else is happening.  What's the last entry in your ChangeLog for the
version you're running?  This will help me identify any source changes you may
not have since you are most likely not running the trunk.
- --
/*
Matt Brookings m...@inter7.com   GnuPG Key FAE0672C
Software developer Systems technician
Inter7 Internet Technologies, Inc. (815)776-9465
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqehJIACgkQIwet2/rgZyzVBACdEJaQM0lZHFiNczoJ1E2Pv7be
WwcAoIv3aTNsQ3gUeQ3OJC6Akok3E3uY
=OmY3
-END PGP SIGNATURE-


Re: [vchkpw] Vusaged segmentation fault on long names

2009-09-02 Thread Wouter van der Schagt

Thank you for the quick reply!


Is this in 5.5?  What are the steps to reproduce?  I added the domain as
you did above, and my vusaged binary from trunk is running as expected,
returning data for the long domain name.


No, this is in 5.4.28, not running 5.5 at the moment, I can reproduce by 
creating a long domainname and starting vusaged.


This would seem to indicate that the issue occurred somewhere in 
vpopmail's

vauth_getall call, or in MySQL itself.

Can you post your vusaged.conf, configure options for the main tree,
and configure options for the MySQL module?


---
./configure \
 --prefix=/home/vpopmail \
 --disable-roaming-users \
 --enable-logging=p \
 --disable-ip-alias-domains \
 --disable-passwd \
 --enable-clear-passwd \
 --disable-domain-quotas \
 --enable-auth-module=mysql \
 --enable-incdir=/usr/include/mysql/ \
 --enable-libdir=/usr/lib/ \
 --disable-many-domains \
 --enable-auth-logging \
 --enable-sql-logging \
 --enable-valias \
 --disable-mysql-limits \
 --enable-tcpserver-file=/etc/tcp.smtp
---
Not using 5.5 so no mysql backend
---

vusaged.conf (without comments)

--

Log:
  Level = 1;

Socket:

  Filename = /tmp/vusaged.sock;
//   Listen = 0.0.0.0:189;
//   Allow = 192.168.1.161 127.0.0.1;

  UID = vpopmail;
  GID = vchkpw;

  Client timeout = 5;  // Inactivity timeout in 
seconds

  Poll timeout = 1;
  Detect client timeout = 4;

Queue:
  Workers = 10;
  Max queue size = 1000;

Polling:

  Use Maildir++ format = True;
  Directory minimum poll time = 120;
  Count directory entry size = True;
 Age Factor = 1;

---

Something else is happening.  What's the last entry in your ChangeLog for 
the
version you're running?  This will help me identify any source changes you 
may

not have since you are most likely not running the trunk.


5.4.28 - Current
  Matt Brookings
  - Updated vlimits_read_vlimits_file to be much more efficient
  - Added vusage client API to libvpopmail
  - Added vusage daemon
  - Updated quota code to talk to vusage daemon if available
  - Fixed some backfill patch compilation issues
  - Updated maildir_to_email to support paths that end in /Maildir as well 
as /Maildir/

  - Added LDAP valias support
  - Updated vusage API to return counts for both users and domains
  - Updated domain quota enforcement to work when using vusage
  - Re-enabled --enable-domainquotas (with warnings)

If you want I can give you remote access to a test server where the problem 
can be reproduced!


Sincerely,
- Wouter van der Schagt 



!DSPAM:4a9e8b6032711366617797!



Re: [vchkpw] Vusaged segmentation fault on long names

2009-09-02 Thread Matt Brookings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Wouter van der Schagt wrote:
 No, this is in 5.4.28, not running 5.5 at the moment, I can reproduce by
 creating a long domainname and starting vusaged.

Ah.  I see this as well.  Looking into this.
- --
/*
Matt Brookings m...@inter7.com   GnuPG Key FAE0672C
Software developer Systems technician
Inter7 Internet Technologies, Inc. (815)776-9465
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqelOUACgkQIwet2/rgZyzWggCeIM1s3tMYiTNt4habSGePofV/
Wy4AnjazC83jc0HlHLs1t5tQ+ijnjUrr
=3+xW
-END PGP SIGNATURE-


Re: [vchkpw] Vusaged segmentation fault on long names

2009-09-02 Thread Matt Brookings
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Wouter van der Schagt wrote:
 Thank you for the quick reply!
 
 Is this in 5.5?  What are the steps to reproduce?  I added the domain as
 you did above, and my vusaged binary from trunk is running as expected,
 returning data for the long domain name.
 
 No, this is in 5.4.28, not running 5.5 at the moment, I can reproduce by
 creating a long domainname and starting vusaged.

The problem appears in the MySQL module.  The temporary fix:

  Edit vauth_munch_domain function, change declaration of tmpbuf size of 50 to 
512.

I will be releasing a better fix shortly.
- --
/*
Matt Brookings m...@inter7.com   GnuPG Key FAE0672C
Software developer Systems technician
Inter7 Internet Technologies, Inc. (815)776-9465
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqer8IACgkQIwet2/rgZyydqQCdFleg33eYc3FxnTGjCGHvnJFc
Yx0An3f/DTLsIGIEXjoV3735oWV/9TOs
=ha7v
-END PGP SIGNATURE-