[vchkpw] Crash in qmailadmin 1.2.10/vpopmail 5.4.16 adding first forward
Seems there's a crash in qmailadmin/vpopmail still when adding only the first forward in a domain. The second works fine, but deleting the first and recreating it even shows an internal server error.I'll have another look at the source, but I think there's still some bugs left to squash.-M
Re: [vchkpw] Crash in qmailadmin 1.2.10/vpopmail 5.4.16 adding first forward
Ken- a segfault patch against 5.4.16 is attached.Since mydir is static (and hence survives the function call), if max_names is null (which happens if there are no aliases on the domain), then mydir has been closed, but mydir is not set to NULL. Hence when it does a second itteration of the function as qmailadmin will, it will segfault since it's not null, yet is closed.See attached,I also attached my patch from earlier regarding forcing at least read/write permissions on the lock file, as I'm finding qmailadmin is creating them with no permissions (likely relating to a umask or something Debian related, so it's always best to force the permissions of the lock file).-MMichael Krieger [EMAIL PROTECTED] wrote: Seems there's a crash in qmailadmin/vpopmail still when adding only the first forward in a domain. The second works fine, but deleting the first and recreating it even shows an internal server error.I'll have another look at the source, but I think there's still some bugs left to squash.-M vpalias.segfault.crash.20060509.patch.gz Description: 3308966721-vpalias.segfault.crash.20060509.patch.gz vpopmail-5.4.16-lockperm.patch.gz Description: 3462119702-vpopmail-5.4.16-lockperm.patch.gz
Re: [vchkpw] Crash in qmailadmin 1.2.10/vpopmail 5.4.16 adding first forward
On May 9, 2006, at 1:58 PM, Michael Krieger wrote: Ken- a segfault patch against 5.4.16 is attached. Since mydir is static (and hence survives the function call), if max_names is null (which happens if there are no aliases on the domain), then mydir has been closed, but mydir is not set to NULL. Hence when it does a second itteration of the function as qmailadmin will, it will segfault since it's not null, yet is closed. See attached, I also attached my patch from earlier regarding forcing at least read/write permissions on the lock file, as I'm finding qmailadmin is creating them with no permissions (likely relating to a umask or something Debian related, so it's always best to force the permissions of the lock file). I'll make sure these get into 5.4.17, and will consider a quick release after a week or so for any remaining bugs to be uncovered. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/
