Re: [vchkpw] [mrsam@courier-mta.com: [sqwebmail] Re: Sqwebmail Authorization 2]
I personally would love to see the MySQL data moved out of the library and into a config file. The thought of recompiling vpopmail if/when my database info changes is disconcerting. Configuration data belongs in configuration files, not shared libraries. The only concern of course is that apps which link against libvpopmail need to know where to get the login info, so perhaps it needs to be made automagical that even a shared library call will open up the config, grab the info and then execute against the correct MySQL server. On Friday 18 July 2003 19:23, Tom Collins wrote: On Friday, July 18, 2003, at 03:55 PM, Doug Clements wrote: It looks like there's 2 main problems he's detailing. The first he details looks pretty darn obviously a bug. Can anyone comment on why this buffer isn't cleared, and why it hasn't been fixed? If someone can give me better guidance, I will go in and fix the problem on the vpopmail side. What functions does authdaemon make use of in libvpopmail? libvpopmail may need a major overhaul and review for memory leaks, especially if it's like QmailAdmin. Since QmailAdmin runs as a CGI, no one has been very careful about freeing allocated memory when it's done being used. I'm not sure if similar coding practices are present in vpopmail. I'm not sure how to address the library problem. I've come across it, and anyone who halfway knows what they're doing should know how to get around it, but we all (sqwebmail and vpopmail lists) still get people who have problems with it. This sounds fixable by the patch I just saw that keeps the authentication information in a seperate file. Are there any objections to doint this and relaxing the restrictions on the lib directory (at least make it executable) and the actual library file (make it readable)? The hard-coded login information was the only valid reason I remember for having the lib permissions like that. Anyone? I liked that patch, and I want to integrate it into an upcoming release (with review from others of course). I agree that the MySQL information should live in a non-world-readable file owned by vpopmail, perhaps stored in ~vpopmail/etc instead of /var/qmail/control. Does anyone see a reason it should be hardcoded into the lib? I've never seen this problem really anaylzed and properly investigated on the vpopmail side. I really would like sqwebmail and vpopmail to work well together, it would be quite a shame to lose the interoperability over some bugs that should really be fixed regardless. I'm not intimately familiar with sqwebmail, but I'll commit to fixing whatever is broken in vpopmail. Should I just examine authvchkpw.c to see how it interfaces to vpopmail, and work on the parts of vpopmail that it touches? Otherwise, it will probably be necessary to review each function in vpopmail to make sure it could be called repeatedly, work properly, and not leak memory. -- Tom Collins [EMAIL PROTECTED] http://sniffter.com/ - info on the Sniffter hand-held Network Tester -- Nicholas Harring System Administrator Webley Systems, Inc. Ph# 877-609-4795
[vchkpw] [mrsam@courier-mta.com: [sqwebmail] Re: Sqwebmail Authorization 2]
- Forwarded message from Sam Varshavchik [EMAIL PROTECTED] - Doug Clements writes: On Fri, Jul 18, 2003 at 09:47:14AM -0400, Sam Varshavchik wrote: Known bug in the vpopmail module. Try the vpopmail mailing list. If vpopmail people do not fix this bug, I'll simply pull the vpopmail module out. I don't want to deal with their bugs any more. I've seen this said many times for years now. vpopmail says it's a bug in authdaemon, you say it's a bug in vpopmail. How specifically does vpopmail act that is problematic for sqwebmail? It fails to clear the buffer where the username is copied to. Therefore, a subsequent authentication request for a username with fewer characters will get leftover crap appended to it, and the userid search against the database will fail. By disabling authdaemon, they're hacking around the bug by starting a new process for each authentication request, with all memory cleared at startup. There's nothing wrong with authdaemon. LDAP, PostgreSQL, or MySQL authentication is rock solid. Only vpopmail craps out, when using authdaemon. It's a vpopmail bug. This is the last time I'm going to address this issue. They'll either have to fix this bug, or if I continue to get their bug reports, I'll just drop the whole vpopmail module. And they also better do something about the broken permissions on the vpopmail library. Not a week goes by without someone whining that linking against -lvpopmail fails. That's because libvpopmail.a does not have group or world read permissions. You want to know why's that? That's because the administrator password to MySQL is hardcoded into the library, and some time ago someone correctly reported to Bugtraq that with vpopmail installed, anyone on the system can easily lift the admin password to MySQL out of libvpopmail.a. So how was that fixed? By removing read permissions on libvpopmail.a. End result? When building sqwebmail or courier-imap as non-root, the link against libvpopmail.a now fails. And I get the bug reports caused by the broken security model of vpopmail. - End forwarded message - It looks like there's 2 main problems he's detailing. The first he details looks pretty darn obviously a bug. Can anyone comment on why this buffer isn't cleared, and why it hasn't been fixed? I'm not sure how to address the library problem. I've come across it, and anyone who halfway knows what they're doing should know how to get around it, but we all (sqwebmail and vpopmail lists) still get people who have problems with it. This sounds fixable by the patch I just saw that keeps the authentication information in a seperate file. Are there any objections to doint this and relaxing the restrictions on the lib directory (at least make it executable) and the actual library file (make it readable)? The hard-coded login information was the only valid reason I remember for having the lib permissions like that. Anyone? I've never seen this problem really anaylzed and properly investigated on the vpopmail side. I really would like sqwebmail and vpopmail to work well together, it would be quite a shame to lose the interoperability over some bugs that should really be fixed regardless. --Doug
Re: [vchkpw] [mrsam@courier-mta.com: [sqwebmail] Re: Sqwebmail Authorization 2]
On Friday, July 18, 2003, at 03:55 PM, Doug Clements wrote: It looks like there's 2 main problems he's detailing. The first he details looks pretty darn obviously a bug. Can anyone comment on why this buffer isn't cleared, and why it hasn't been fixed? If someone can give me better guidance, I will go in and fix the problem on the vpopmail side. What functions does authdaemon make use of in libvpopmail? libvpopmail may need a major overhaul and review for memory leaks, especially if it's like QmailAdmin. Since QmailAdmin runs as a CGI, no one has been very careful about freeing allocated memory when it's done being used. I'm not sure if similar coding practices are present in vpopmail. I'm not sure how to address the library problem. I've come across it, and anyone who halfway knows what they're doing should know how to get around it, but we all (sqwebmail and vpopmail lists) still get people who have problems with it. This sounds fixable by the patch I just saw that keeps the authentication information in a seperate file. Are there any objections to doint this and relaxing the restrictions on the lib directory (at least make it executable) and the actual library file (make it readable)? The hard-coded login information was the only valid reason I remember for having the lib permissions like that. Anyone? I liked that patch, and I want to integrate it into an upcoming release (with review from others of course). I agree that the MySQL information should live in a non-world-readable file owned by vpopmail, perhaps stored in ~vpopmail/etc instead of /var/qmail/control. Does anyone see a reason it should be hardcoded into the lib? I've never seen this problem really anaylzed and properly investigated on the vpopmail side. I really would like sqwebmail and vpopmail to work well together, it would be quite a shame to lose the interoperability over some bugs that should really be fixed regardless. I'm not intimately familiar with sqwebmail, but I'll commit to fixing whatever is broken in vpopmail. Should I just examine authvchkpw.c to see how it interfaces to vpopmail, and work on the parts of vpopmail that it touches? Otherwise, it will probably be necessary to review each function in vpopmail to make sure it could be called repeatedly, work properly, and not leak memory. -- Tom Collins [EMAIL PROTECTED] http://sniffter.com/ - info on the Sniffter hand-held Network Tester
Re: [vchkpw] [mrsam@courier-mta.com: [sqwebmail] Re: Sqwebmail Authorization 2]
On Fri, Jul 18, 2003 at 05:23:58PM -0700, Tom Collins wrote: On Friday, July 18, 2003, at 03:55 PM, Doug Clements wrote: It looks like there's 2 main problems he's detailing. The first he details looks pretty darn obviously a bug. Can anyone comment on why this buffer isn't cleared, and why it hasn't been fixed? If someone can give me better guidance, I will go in and fix the problem on the vpopmail side. What functions does authdaemon make use of in libvpopmail? I would imagine it only uses the password lookup functions. vpopmail is pretty darn simple, there's not that many ways to lookup a password. libvpopmail may need a major overhaul and review for memory leaks, especially if it's like QmailAdmin. Since QmailAdmin runs as a CGI, no one has been very careful about freeing allocated memory when it's done being used. I'm not sure if similar coding practices are present in vpopmail. There doesn't appear to be from what I've seen, and random segfaults and crashes of various vpopmail processes strenthe my opinion. vpopmail seems to have more of a fix things when they cause problems way of going. Does anyone see a reason it should be hardcoded into the lib? The only one I can think of is speed, but really when you're using mysql, the hit of opening another file will be much lower than that of even connecting to the sql server and just logging in, not counting query time. I'm not intimately familiar with sqwebmail, but I'll commit to fixing whatever is broken in vpopmail. Should I just examine authvchkpw.c to see how it interfaces to vpopmail, and work on the parts of vpopmail that it touches? Otherwise, it will probably be necessary to review each function in vpopmail to make sure it could be called repeatedly, work properly, and not leak memory. I would just look through it.. I would love to get in there, but my to-do list is huge already. Seems some sort of regression testing app would be pretty easy to code up that does what you describe. Catching the bug he describes of reusing a buffer without clearing it should be pretty easy to find. He even tells us it's the username field, so good hunting! --Doug
