Re: [vchkpw] Re: [qmailadmin] Re: PHP vpopmail extension
Existence wrote: Rick Widmer wrote: That is what i meant, not everyone is able to have a special server just for mail, and thus running Apache as vpopmail:vchkpw is not an option. If you created some sort of deamon that allows you with public and privatekey's to communicate. Then you can run apache as www:www and not have to worry about users being able to alter vpopmail stuff cause of the mail server running under vpopmail:vchkpw. It is very easy to start a second instance of Apache. Just create a second httpd.conf file with different users, different DocumentRoot and add Listen directives to both httpd.conf files specifying which ports and IP addresses each server handles. The more I think about it the more it looks like the most secure solution. (Other than a separate mail server.) A binary that handled a few information retrieval functions is probably all that would be needed. I think there would be about 4-6 functions it should be able to return data from. I actually considered writing it before I decided to attack the PHP extension. For the rest we may as well exec the existing progtrams and not re-invent existing functionality. I've already got a PHP program that manages mail domains that way, but it reads the ~vpopmail/domains/ directory to get all its information. Well, what i meant is that having one binary that can do everything in one, is easier than having to run several different commands each time to add or remove domains, and having to parse different output each time. I personally might start on this, if i get the chance, as it would be a lot better than running apache as the mail user, when other there are other websites on it. If you do, please be sure to implement security within your program. Each page hit the php program needs to pass user supplied credentials so you can verify the user. The vpopmail library does not do this security checking, so you have to. If the vpopmail library becomes directly available to anyone running as www:www, they can do ANYTHING to your mail accounts. Rick
Re: [vchkpw] Re: [qmailadmin] Re: PHP vpopmail extension
Rick Widmer wrote: Existence wrote: Rick Widmer wrote: That is what i meant, not everyone is able to have a special server just for mail, and thus running Apache as vpopmail:vchkpw is not an option. If you created some sort of deamon that allows you with public and privatekey's to communicate. Then you can run apache as www:www and not have to worry about users being able to alter vpopmail stuff cause of the mail server running under vpopmail:vchkpw. It is very easy to start a second instance of Apache. Just create a second httpd.conf file with different users, different DocumentRoot and add Listen directives to both httpd.conf files specifying which ports and IP addresses each server handles. The more I think about it the more it looks like the most secure solution. (Other than a separate mail server.) I personally dont like the idea that i have to use resources on two running Apache's, but it is indeed possible. A binary that handled a few information retrieval functions is probably all that would be needed. I think there would be about 4-6 functions it should be able to return data from. I actually considered writing it before I decided to attack the PHP extension. For the rest we may as well exec the existing progtrams and not re-invent existing functionality. I've already got a PHP program that manages mail domains that way, but it reads the ~vpopmail/domains/ directory to get all its information. Well, what i meant is that having one binary that can do everything in one, is easier than having to run several different commands each time to add or remove domains, and having to parse different output each time. I personally might start on this, if i get the chance, as it would be a lot better than running apache as the mail user, when other there are other websites on it. If you do, please be sure to implement security within your program. Each page hit the php program needs to pass user supplied credentials so you can verify the user. The vpopmail library does not do this security checking, so you have to. If the vpopmail library becomes directly available to anyone running as www:www, they can do ANYTHING to your mail accounts. Yeah, that much i have figured out :P. I would use http auth, and then use the checkpasswd implementation in this long running deamon, to check if it is correct or not, if it is not correct, we drop the connection, if this happens 3 times in a row, that user is disallowed to contact the deamon again, until they have waited 1 hour. Rick
Re: [vchkpw] Re: [qmailadmin] Re: PHP vpopmail extension
X-Istence wrote: Rick Widmer wrote (At least in part): I am adding the following functions to vpopmail: valias_select_names, valias_select_names_next, valias_select_names_end Kinda like C++'s std::vector things, allowing you to walk thru an array of aliased domain names. I don't know about std::vector, this is stolen from valias_select_all() and valias_select_all_next(). I wanted just the alias names, preferably sorted. Since it is so easy from any of the database front ends, I decided to sort the names for cdb and say vpopmail always returns them sorted. That is very handy for QmailAdmin... it does't have to sort them. Submit a patch on sourceforge is what tom would say :P Already done... :P [ 895348 ] Ordered Alias Names for cdb I am testing the extension running PHP as an Apache module, with Apache running as vpopmail:vchkpw. I think it should also run from CGI as long as it is run as the vpopmail user. I don't see any way to get around running as the mail system user, and considering how easy it is to setup a separate instance of Apache I don't see any reason to worry about anything else. If you don't agree, now is the time to show me a better way. How about a public private key sort of thing like SSH? For what? As I see it the vpopmail extension for PHP is for web servers that are running on the mail server, like QmailAdmin or sqWebmail are run now. Since everything is done by one process I don't see any need for fancy communications in the extension. Using named pipes as a means to talk to each other. This would require a deamon. If I had that daemon, I wouldn't bother with an extension. It would be much easier to code a library in PHP to accesses the daemon. Hitting something like this via a SSH tunnel would be very cool! You could manage a mail server from many web servers. It is serious overkill for what I want. This little project is about using PHP for prototyping the user interface for QmailAdmin 1.3. Or even, just exec, and having a binary setuid vpopmail:vchkpw and talk over stdin, and stdout. A binary that handled a few information retrieval functions is probably all that would be needed. I think there would be about 4-6 functions it should be able to return data from. I actually considered writing it before I decided to attack the PHP extension. For the rest we may as well exec the existing progtrams and not re-invent existing functionality. I've already got a PHP program that manages mail domains that way, but it reads the ~vpopmail/domains/ directory to get all its information. This would be better than running apache as vpopmail:vchkpw.i prefer not to run two different apache's side by side, just one, running as www:www :) I don't run two web servers side by side either... the ONLY things Apache does on my mail server are mail related. There are NO web sites and very few people who login to it directly. I see it as an extension of the mail system, not a web server, so running as the vpopmail user is natural. So far the only things I don't know how to handle from running apache as vpopmail is adding and removing domains. Specificly altering the /var/qmail/users/* and signaling qmail. I will take the easy way out and just exec the vpopmail programs. The real goal here is working the bugs out of the user interface for the next generation of QmailAdmin before I commit the code to C. The updated vpopmail module is just a side effect. :) Since I haven't heard from anyone actually using the extension, I think I am going to just rip out the code that checks for ancient versions of vpopmail, add a note that says it Requires vpopmail 5.4.2 or newer and call it good. If someone actually needs to use an older version, some of the code can be #ifdef'ed out later. Thanks for responding... Rick
Re: [vchkpw] Re: [qmailadmin] Re: PHP vpopmail extension
Rick Widmer wrote: X-Istence wrote: Rick Widmer wrote (At least in part): I am adding the following functions to vpopmail: valias_select_names, valias_select_names_next, valias_select_names_end Kinda like C++'s std::vector things, allowing you to walk thru an array of aliased domain names. I don't know about std::vector, this is stolen from valias_select_all() and valias_select_all_next(). I wanted just the alias names, preferably sorted. Since it is so easy from any of the database front ends, I decided to sort the names for cdb and say vpopmail always returns them sorted. That is very handy for QmailAdmin... it does't have to sort them. Makes sense. Would make it a whole lot easier to parse the names coming at you, and no need to allocate more memory for sorting and then outputting it, output as it comes along. Submit a patch on sourceforge is what tom would say :P Already done... :P [ 895348 ] Ordered Alias Names for cdb I am testing the extension running PHP as an Apache module, with Apache running as vpopmail:vchkpw. I think it should also run from CGI as long as it is run as the vpopmail user. I don't see any way to get around running as the mail system user, and considering how easy it is to setup a separate instance of Apache I don't see any reason to worry about anything else. If you don't agree, now is the time to show me a better way. How about a public private key sort of thing like SSH? For what? As I see it the vpopmail extension for PHP is for web servers that are running on the mail server, like QmailAdmin or sqWebmail are run now. Since everything is done by one process I don't see any need for fancy communications in the extension. That is what i meant, not everyone is able to have a special server just for mail, and thus running Apache as vpopmail:vchkpw is not an option. If you created some sort of deamon that allows you with public and privatekey's to communicate. Then you can run apache as www:www and not have to worry about users being able to alter vpopmail stuff cause of the mail server running under vpopmail:vchkpw. Using named pipes as a means to talk to each other. This would require a deamon. If I had that daemon, I wouldn't bother with an extension. It would be much easier to code a library in PHP to accesses the daemon. Hitting something like this via a SSH tunnel would be very cool! You could manage a mail server from many web servers. It is serious overkill for what I want. This little project is about using PHP for prototyping the user interface for QmailAdmin 1.3. Or even, just exec, and having a binary setuid vpopmail:vchkpw and talk over stdin, and stdout. A binary that handled a few information retrieval functions is probably all that would be needed. I think there would be about 4-6 functions it should be able to return data from. I actually considered writing it before I decided to attack the PHP extension. For the rest we may as well exec the existing progtrams and not re-invent existing functionality. I've already got a PHP program that manages mail domains that way, but it reads the ~vpopmail/domains/ directory to get all its information. Well, what i meant is that having one binary that can do everything in one, is easier than having to run several different commands each time to add or remove domains, and having to parse different output each time. I personally might start on this, if i get the chance, as it would be a lot better than running apache as the mail user, when other there are other websites on it. This would be better than running apache as vpopmail:vchkpw.i prefer not to run two different apache's side by side, just one, running as www:www :) I don't run two web servers side by side either... the ONLY things Apache does on my mail server are mail related. There are NO web sites and very few people who login to it directly. I see it as an extension of the mail system, not a web server, so running as the vpopmail user is natural. Not everyone has the ability to have one server just for mail, which is why i suggest some sort of deamon, or a program that is setuid, to execute and talk with.. snip Thanks for responding... Rick
Re: [vchkpw] Re: [qmailadmin] Re: PHP vpopmail extension
Rick Widmer wrote (At least in part): snip I am adding the following functions to vpopmail (If Tom allows them...) and adding support for them in the extension: valias_select_names, valias_select_names_next, valias_select_names_end Kinda like C++'s std::vector things, allowing you to walk thru an array of aliased domain names. Submit a patch on sourceforge is what tom would say :P These functions retrieve just the sorted names of aliases for a domain. I just got it to compile with no errors for the first time. There are probably a couple of days of testing before I publish the code. I think there is a conflict in the version checking code in config.m4 and the latest version of vpopmail. I just added some #define's and #undefs in the code to bypass it. I believe something better must be done before it is submitted to PECL, but that is not very high on my prioroty list. I am testing the extension running PHP as an Apache module, with Apache running as vpopmail:vchkpw. I think it should also run from CGI as long as it is run as the vpopmail user. I don't see any way to get around running as the mail system user, and considering how easy it is to setup a separate instance of Apache I don't see any reason to worry about anything else. If you don't agree, now is the time to show me a better way. How about a public private key sort of thing like SSH? Using named pipes as a means to talk to each other. This would require a deamon. Or even, just exec, and having a binary setuid vpopmail:vchkpw and talk over stdin, and stdout. Redirecting stderr to a log file of some sort, to log bad auth's, and good ones. And the changes done. This would be better than running apache as vpopmail:vchkpw. But that is totally up to you, i prefer not to run two different apache's side by side, just one, running as www:www :) X-Istence
Re: [vchkpw] Re: [qmailadmin] Re: PHP vpopmail extension
On Mon, 2004-02-16 at 21:19, X-Istence wrote: If you don't agree, now is the time to show me a better way. How about a public private key sort of thing like SSH? Using named pipes as a means to talk to each other. This would require a deamon. Or even, just exec, and having a binary setuid vpopmail:vchkpw and talk over stdin, and stdout. Redirecting stderr to a log file of some sort, to log bad auth's, and good ones. And the changes done. This would be better than running apache as vpopmail:vchkpw. But that is totally up to you, i prefer not to run two different apache's side by side, just one, running as www:www :) vmailmgr does such a thing since there isn't just one user for all domains. It's quite handy, using ucspi-unix and having php talk to the socket and speaking a protocol. coupled with vmail.inc, you can do just about anything with vmailmgr and php. I think there's a squirrelmail plugin for it, which is pretty nice, since then users don't have to log into a seperate interface to change password, vacation reply, etc. I think a daemon would be an excellent addition to vpopmail. -Jeremy -- Jeremy Kitchen Systems Administrator [EMAIL PROTECTED] Kitchen @ #qmail on EFNet - Join the party! . Inter7 Internet Technologies, Inc. www.inter7.com 866.528.3530 toll free 847.492.0470 int'l 847.492.0632 fax GNUPG key ID: 93BDD6CE
[vchkpw] Re: [qmailadmin] Re: PHP vpopmail extension
qmadmin wrote: I'm interested in the PHP extensions you have for the current versions of vpopmail. Since I got more than one response, I'll answer on the list... I have changed vpopmail_auth_user (which calls vauth_user) so it returns false if the username/password/domain is invalid, or for a good login an array containing the password file information for the current user. The existing function only returns true/false. I am adding support for the following vpopmail functions: vset_limits, vdel_limits, (vget_limits is already there) vset_lastauth, vget_lastauth, vget_lastauthip, vget_ip_map, vadd_ip_map, vdel_ip_map, vshow_ip_map, vauth_getpw, vauth_getall, valias_remove valias_select_names I am adding the following functions to vpopmail (If Tom allows them...) and adding support for them in the extension: valias_select_names, valias_select_names_next, valias_select_names_end These functions retrieve just the sorted names of aliases for a domain. I just got it to compile with no errors for the first time. There are probably a couple of days of testing before I publish the code. I think there is a conflict in the version checking code in config.m4 and the latest version of vpopmail. I just added some #define's and #undefs in the code to bypass it. I believe something better must be done before it is submitted to PECL, but that is not very high on my prioroty list. I am testing the extension running PHP as an Apache module, with Apache running as vpopmail:vchkpw. I think it should also run from CGI as long as it is run as the vpopmail user. I don't see any way to get around running as the mail system user, and considering how easy it is to setup a separate instance of Apache I don't see any reason to worry about anything else. If you don't agree, now is the time to show me a better way. Have you also done any work on extensions for ezmlm-idx? No, and I don't think there is anything that deserves to be in an extension. The vpopmail extension is an adapter to the libvpopmail library. Ezmlm is a program, all you do is select the parameters and exec() the program. That is easier to do in PHP, I can't see any advantage to doing it in a c extension.
