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!



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 BrookingsGnuPG 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-


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 BrookingsGnuPG 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 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:
> 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 BrookingsGnuPG 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-