Re: Solution for mail pseudo-users?
On Tue, Aug 03, 1999 at 02:22:17PM -0700, Alex Zepeda wrote: Also you'll have to run the script to allow users to change passwords as "root", which you probably will NOT want to do (same for adding/ deleting/changing users) So with your setup, any user can add/delete/modify existing users? Yeah, that's secure. With your setup that would hold, too. But with my setup the effective user doesn't have to be root, so if there is an exploit the intruder doesn't gain root privileges the first place and it reduces the possibilities that e.g. the whole subnet is compromised by sniffing or the like. Also with 3+ (maybe even with 1+) users each rebuild of the passwd database will become SLOW and you have to take care about locking and such ... been there, tried it, didn't like it. Yes, but with 100k+ users, a database (that requires slow rebuilding) is faster to find random records in than a flat text file. In fact, perhaps you should have instituted some sort of cron'd rebuild (once every 30 minutes for instance), and then queued the changes, so as to prevent users from frobbing in an incorrect manner. A e.g. database isn't a flat text file. Nobody said that one should use a linear search on a flat text file. You're free to plug in whatever backend you want (Berkley DB, SQL database, cdb, ...), but you don't have to rebuild the whole database, but just the record modified. Queuing changes is IMHO not an option. When a user changes his password, he want it to be effective immediately, not after 5, 10, 15 oder 30 minutes. \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses Research Development| mailto:[EMAIL PROTECTED] | you funny and you need Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete files D-80807 Muenchen | Fax: +49 (89) 32356-299 | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
On Tue, Aug 03, 1999 at 02:22:17PM -0700, Alex Zepeda wrote: Also you'll have to run the script to allow users to change passwords as root, which you probably will NOT want to do (same for adding/ deleting/changing users) So with your setup, any user can add/delete/modify existing users? Yeah, that's secure. With your setup that would hold, too. But with my setup the effective user doesn't have to be root, so if there is an exploit the intruder doesn't gain root privileges the first place and it reduces the possibilities that e.g. the whole subnet is compromised by sniffing or the like. Also with 3+ (maybe even with 1+) users each rebuild of the passwd database will become SLOW and you have to take care about locking and such ... been there, tried it, didn't like it. Yes, but with 100k+ users, a database (that requires slow rebuilding) is faster to find random records in than a flat text file. In fact, perhaps you should have instituted some sort of cron'd rebuild (once every 30 minutes for instance), and then queued the changes, so as to prevent users from frobbing in an incorrect manner. A e.g. database isn't a flat text file. Nobody said that one should use a linear search on a flat text file. You're free to plug in whatever backend you want (Berkley DB, SQL database, cdb, ...), but you don't have to rebuild the whole database, but just the record modified. Queuing changes is IMHO not an option. When a user changes his password, he want it to be effective immediately, not after 5, 10, 15 oder 30 minutes. \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses Research Development| mailto:maex-...@space.net | you funny and you need Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete files D-80807 Muenchen | Fax: +49 (89) 32356-299 | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
:On Tue, 3 Aug 1999, Markus Stumpf wrote: : : I just don't see any justification in hacking away at all of your software : to bypass the passwd database. What is gained? : : If you have 10+ users you'll run out of UIDs (see recent thread). : :I find it hard to believe that handling 100,000 users on one box is a good :idea in the first place. : : Also you'll have to run the script to allow users to change passwords as : "root", which you probably will NOT want to do (same for adding/ : deleting/changing users) : :So with your setup, any user can add/delete/modify existing users? Yeah, :that's secure. : : Also with 3+ (maybe even with 1+) users each rebuild of the : passwd database will become SLOW and you have to take care about locking : and such ... been there, tried it, didn't like it. : :Yes, but with 100k+ users, a database (that requires slow rebuilding) is :faster to find random records in than a flat text file. In fact, perhaps :you should have instituted some sort of cron'd rebuild (once every 30 :minutes for instance), and then queued the changes, so as to prevent users :from frobbing in an incorrect manner. : :- alex : :You better believe that marijuana can cause castration. Just suppose your :girlfriend gets the munchies! I'm going to try again. The last response I posted to the wrong thread. This is what I do. I create a pseudo domain and a separate kmap in sendmail and route the mail to a separate backend. There are no user id's to have to worry about. The password file is not involved at all. Here's an example. S98 # ... whatever else was in ruleset 98 before ... R$+ + $* @ pplus . $=w $* $#popplus $: $1 @ pplus . $3 $4 R$+ + $* @ pplus . $=w . $* $#popplus $: $1 @ pplus . $3 $4 R$* @ pplus . $=w $*$#popplus $: $1 @ pplus . $2 $3 R$* @ pplus . $=w . $* $#popplus $: $1 @ pplus . $2 $3 Add to the SBasic_check_rcpt rule: R$+ @ pplus . $=w$@ OK Add to the mailers ( this is just an example, you would need to construct your own backend though, I suppose, I could make my dpopper backend available. It is not 100% finished though ). Mpopplus, P=/usr/local/bin/dpopmail, F=SDEFhlMsu, S=10/30, R=20/40, U=dpop, A=dpopmail $u Then all I do is create entries in my forwarding Kmaps or aliases file to direct somecomplexusername to [EMAIL PROTECTED] Ok, that seems a bit more complex that it really is, but if you are handling hundreds or thousands of users it is worth the trouble to setup something like this. Sendmail operates off of KMap's ... basically dbmed map files. At BEST, before I left, some of our sendmail KMaps had over a fifty-thousand entries in them. It's worth doing. Linear files are death. You can easily support several hundred thousand users with a setup like this. Even more. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
I would recommend qmail (http://www.qmail.org/). It has a VERY modular structure, where you e.g. can easily substitue the checkpassword module with a e.g. perl script doing the lookups. Nothing else needs to be patched/changed and the described scenario can be accomplished with standard qmail features. We're running kind of such a setup for about 2 years and are very happy. There are patches+docs for a complete qmail+mysql integration at http://www.softagency.co.jp/mysql/qmail.en.html There are patches+docs for a complete qmail+ldap integration at http://www.nrg4u.com/ LDAP is not that messy :-) LDAP is designed with a lot of read accesses in mind and will eventually not scale well with a lot of write (change) accesses. On Sun, Aug 01, 1999 at 04:08:00AM -0700, Alex Zepeda wrote: I just don't see any justification in hacking away at all of your software to bypass the passwd database. What is gained? If you have 10+ users you'll run out of UIDs (see recent thread). Also you'll have to run the script to allow users to change passwords as root, which you probably will NOT want to do (same for adding/ deleting/changing users) Also with 3+ (maybe even with 1+) users each rebuild of the passwd database will become SLOW and you have to take care about locking and such ... been there, tried it, didn't like it. \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses Research Development| mailto:maex-...@space.net | you funny and you need Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete files D-80807 Muenchen | Fax: +49 (89) 32356-299 | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
On Tue, 3 Aug 1999, Markus Stumpf wrote: I just don't see any justification in hacking away at all of your software to bypass the passwd database. What is gained? If you have 10+ users you'll run out of UIDs (see recent thread). I find it hard to believe that handling 100,000 users on one box is a good idea in the first place. Also you'll have to run the script to allow users to change passwords as root, which you probably will NOT want to do (same for adding/ deleting/changing users) So with your setup, any user can add/delete/modify existing users? Yeah, that's secure. Also with 3+ (maybe even with 1+) users each rebuild of the passwd database will become SLOW and you have to take care about locking and such ... been there, tried it, didn't like it. Yes, but with 100k+ users, a database (that requires slow rebuilding) is faster to find random records in than a flat text file. In fact, perhaps you should have instituted some sort of cron'd rebuild (once every 30 minutes for instance), and then queued the changes, so as to prevent users from frobbing in an incorrect manner. - alex You better believe that marijuana can cause castration. Just suppose your girlfriend gets the munchies! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
:On Tue, 3 Aug 1999, Markus Stumpf wrote: : : I just don't see any justification in hacking away at all of your software : to bypass the passwd database. What is gained? : : If you have 10+ users you'll run out of UIDs (see recent thread). : :I find it hard to believe that handling 100,000 users on one box is a good :idea in the first place. : : Also you'll have to run the script to allow users to change passwords as : root, which you probably will NOT want to do (same for adding/ : deleting/changing users) : :So with your setup, any user can add/delete/modify existing users? Yeah, :that's secure. : : Also with 3+ (maybe even with 1+) users each rebuild of the : passwd database will become SLOW and you have to take care about locking : and such ... been there, tried it, didn't like it. : :Yes, but with 100k+ users, a database (that requires slow rebuilding) is :faster to find random records in than a flat text file. In fact, perhaps :you should have instituted some sort of cron'd rebuild (once every 30 :minutes for instance), and then queued the changes, so as to prevent users :from frobbing in an incorrect manner. : :- alex : :You better believe that marijuana can cause castration. Just suppose your :girlfriend gets the munchies! I'm going to try again. The last response I posted to the wrong thread. This is what I do. I create a pseudo domain and a separate kmap in sendmail and route the mail to a separate backend. There are no user id's to have to worry about. The password file is not involved at all. Here's an example. S98 # ... whatever else was in ruleset 98 before ... R$+ + $* @ pplus . $=w $* $#popplus $: $1 @ pplus . $3 $4 R$+ + $* @ pplus . $=w . $* $#popplus $: $1 @ pplus . $3 $4 R$* @ pplus . $=w $*$#popplus $: $1 @ pplus . $2 $3 R$* @ pplus . $=w . $* $#popplus $: $1 @ pplus . $2 $3 Add to the SBasic_check_rcpt rule: R$+ @ pplus . $=w$@ OK Add to the mailers ( this is just an example, you would need to construct your own backend though, I suppose, I could make my dpopper backend available. It is not 100% finished though ). Mpopplus, P=/usr/local/bin/dpopmail, F=SDEFhlMsu, S=10/30, R=20/40, U=dpop, A=dpopmail $u Then all I do is create entries in my forwarding Kmaps or aliases file to direct somecomplexusername to usern...@pplus.my.domain. Ok, that seems a bit more complex that it really is, but if you are handling hundreds or thousands of users it is worth the trouble to setup something like this. Sendmail operates off of KMap's ... basically dbmed map files. At BEST, before I left, some of our sendmail KMaps had over a fifty-thousand entries in them. It's worth doing. Linear files are death. You can easily support several hundred thousand users with a setup like this. Even more. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
On Sat, 31 Jul 1999, Alex Zepeda wrote: The easiest way I can think of would be to add them to /etc/passwd and set their shell and home dir to /nonexistant. Ideally you wouldn't be running any other daemons, so there'd be no real way for them to access files; but the stock ftpd, as well as sshd offer ways to disable access to specific users. Dealing with "real" users IMO is quite a bit less hackish. I like the 'keeping it real' idea as well. Then again, doesn't 3.2R+ support SecureRPC? Isn't this the sort of thing NIS+ was invented for? A centralized db of users that you can then export to various machines with differing characteristics? I.e. couldn't you import the NIS db to your mail box(es) with /nonexistent home directory and /sbin/nologin shell? Name and password pairs would still exist, allowing any SMTP/POP3 daemons I know of to work without change. If NIS sends chills down your spine, I guess you could also do a bit of non-daemon-based hackage... make a script replace the home directory and shell fields with appropriate values in a copied passwd and rsync the thing to your mail boxes... Then again, SQL seems to be the current buzz... Having SQL-based access is cool/manageable (a friend generates the MySQL db from his Radius users file). As usual, there's more than one way to skin a cat. Later, --mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
Then again, SQL seems to be the current buzz... Having SQL-based access is cool/manageable (a friend generates the MySQL db from his Radius users file). And we do it the other way: Generate the users file from mysql. I rather prefer it like that; then I can still auth users, if mysql goes down. Also, it saved my a$$ once; mysql lacking commit and rollback. I was disturbed into firing off an update command before having typed the where-clause. I then locked the password of every user, instead of only the users belonging to a single client... Luckily, I dump the database every hour, and rcs it, so I can recreate the database at any hourly version the last few months. Leif As usual, there's more than one way to skin a cat. Yeah.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
On Sun, Aug 01, 1999 at 02:43:28AM -0700, Mike Hoskins wrote: I like the 'keeping it real' idea as well. Then again, doesn't 3.2R+ support SecureRPC? Isn't this the sort of thing NIS+ was invented for? A centralized db of users that you can then export to various machines with differing characteristics? I.e. couldn't you import the NIS db to your mail box(es) with /nonexistent home directory and /sbin/nologin shell? Name and password pairs would still exist, allowing any SMTP/POP3 daemons I know of to work without change. We support NIS, and secure RPC, but not NIS+. Bill Paul was working on it some time back, but I'm not sure if he still is... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
On Sat, 31 Jul 1999, Alex Zepeda wrote: The easiest way I can think of would be to add them to /etc/passwd and set their shell and home dir to /nonexistant. Ideally you wouldn't be running any other daemons, so there'd be no real way for them to access files; but the stock ftpd, as well as sshd offer ways to disable access to specific users. Dealing with real users IMO is quite a bit less hackish. I like the 'keeping it real' idea as well. Then again, doesn't 3.2R+ support SecureRPC? Isn't this the sort of thing NIS+ was invented for? A centralized db of users that you can then export to various machines with differing characteristics? I.e. couldn't you import the NIS db to your mail box(es) with /nonexistent home directory and /sbin/nologin shell? Name and password pairs would still exist, allowing any SMTP/POP3 daemons I know of to work without change. If NIS sends chills down your spine, I guess you could also do a bit of non-daemon-based hackage... make a script replace the home directory and shell fields with appropriate values in a copied passwd and rsync the thing to your mail boxes... Then again, SQL seems to be the current buzz... Having SQL-based access is cool/manageable (a friend generates the MySQL db from his Radius users file). As usual, there's more than one way to skin a cat. Later, --mike To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Then again, SQL seems to be the current buzz... Having SQL-based access is cool/manageable (a friend generates the MySQL db from his Radius users file). And we do it the other way: Generate the users file from mysql. I rather prefer it like that; then I can still auth users, if mysql goes down. Also, it saved my a$$ once; mysql lacking commit and rollback. I was disturbed into firing off an update command before having typed the where-clause. I then locked the password of every user, instead of only the users belonging to a single client... Luckily, I dump the database every hour, and rcs it, so I can recreate the database at any hourly version the last few months. Leif As usual, there's more than one way to skin a cat. Yeah.. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
On Sun, 1 Aug 1999, Mike Hoskins wrote: As usual, there's more than one way to skin a cat. And as always a bloodless vegetarian way too :) I just don't see any justification in hacking away at all of your software to bypass the passwd database. What is gained? - alex You better believe that marijuana can cause castration. Just suppose your girlfriend gets the munchies! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
On Sun, Aug 01, 1999 at 02:43:28AM -0700, Mike Hoskins wrote: I like the 'keeping it real' idea as well. Then again, doesn't 3.2R+ support SecureRPC? Isn't this the sort of thing NIS+ was invented for? A centralized db of users that you can then export to various machines with differing characteristics? I.e. couldn't you import the NIS db to your mail box(es) with /nonexistent home directory and /sbin/nologin shell? Name and password pairs would still exist, allowing any SMTP/POP3 daemons I know of to work without change. We support NIS, and secure RPC, but not NIS+. Bill Paul was working on it some time back, but I'm not sure if he still is... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Solution for mail pseudo-users?
Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Do not ask me to RTFM on PAM, for PAM does not allow me to add users not mentioned in passwd. As far as I understand, LDAP is rather bulky and suited to X.500 integration, and that is not what I want. Any suggestions, anyone? Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
Alex Povolotsky wrote: Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
[EMAIL PROTECTED]Sergey Babkin writes: Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. And modify sendmail to throw off mail for nonexistent users? Alex. -- Alexander B. Povolotsky[ICQ 18277558] [2:5020/145] [http://freebsd.svib.ru] [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
On Sat, 31 Jul 1999, Alex Povolotsky wrote: I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. Use Cyrus :) The web pages at http://andrew2.andrew.cmu.edu/cyrus/ are horribly out of date, but the project is still active, and there's recent code in the FTP area. Cheers, Mick The Reverend Jasper P. O'Malley dotdot:[EMAIL PROTECTED] Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
I don't know if my previous send was successfull, so I will send again. MY apollogies if a copy of this email is already/has already been delivered. Alex, You may want to try the patches for qpopper (if this is what you're using) to connect to a MySQL db for this sort of stuff. If you don't like qpopper, implementing these sorts of changes is generally easy and not very time-consuming for most POP daemons that come with the source. Also, a patch for smtp (sendmail+MySQL) is in the works, you may want to look at http://www.colba.net/~paul/projects/ Cheers. _. Bosko Milekic [EMAIL PROTECTED] | Network Operations Delphi SuperNet | http://www.dsuper.net/ an Internet Direct company | +1.514.281.7500, x233 (phone) +1.514.281.6599 (fax) | http://www.dsuper.net/~bmilekic/| _| On Sat, 31 Jul 1999, Alex Povolotsky wrote: Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Do not ask me to RTFM on PAM, for PAM does not allow me to add users not mentioned in passwd. As far as I understand, LDAP is rather bulky and suited to X.500 integration, and that is not what I want. Any suggestions, anyone? Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution for mail pseudo-users?
Hi Alex, Alex Povolotsky [EMAIL PROTECTED] wrote: I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. cucipop is fairly simple to modify (it's well structured for change) and I've managed to hack in bits of merit radius client code into it once or twice -- to authenticate POP clients from the local radius server... sendmail local delivery was a pain, I ended up fudging that with an additional aliases file mapping names to files (ugh!)... Cheers Leigh -- | "By the time they had diminished | Leigh Hart, [EMAIL PROTECTED] | | from 50 to 8, the other dwarves | CCNA - http://www.cisco.com/ | | began to suspect 'Hungry' ..." | GPO Box 487 Adelaide SA 5001 | | -- Gary Larson, "The Far Side" | http://www.dotat.com/hart/ | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Solution for mail pseudo-users?
Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Do not ask me to RTFM on PAM, for PAM does not allow me to add users not mentioned in passwd. As far as I understand, LDAP is rather bulky and suited to X.500 integration, and that is not what I want. Any suggestions, anyone? Alex. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Alex Povolotsky wrote: Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
37a30852.20e5a...@bellatlantic.netSergey Babkin writes: Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. And modify sendmail to throw off mail for nonexistent users? Alex. -- Alexander B. Povolotsky[ICQ 18277558] [2:5020/145] [http://freebsd.svib.ru] [tark...@asteroid.svib.ru] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
On Sat, 31 Jul 1999, Alex Povolotsky wrote: I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. Use Cyrus :) The web pages at http://andrew2.andrew.cmu.edu/cyrus/ are horribly out of date, but the project is still active, and there's recent code in the FTP area. Cheers, Mick The Reverend Jasper P. O'Malley dotdot:jo...@webnology.com Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Alex Povolotsky wrote: 37a30852.20e5a...@bellatlantic.netSergey Babkin writes: Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. And modify sendmail to throw off mail for nonexistent users? Try Postfix instead of sendmail. It will come out much easier. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org - Jordan, God, what's the difference? - God doesn't belong to the -core. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
I don't know if my previous send was successfull, so I will send again. MY apollogies if a copy of this email is already/has already been delivered. Alex, You may want to try the patches for qpopper (if this is what you're using) to connect to a MySQL db for this sort of stuff. If you don't like qpopper, implementing these sorts of changes is generally easy and not very time-consuming for most POP daemons that come with the source. Also, a patch for smtp (sendmail+MySQL) is in the works, you may want to look at http://www.colba.net/~paul/projects/ Cheers. _. Bosko Milekic bmile...@dsuper.net | Network Operations Delphi SuperNet | http://www.dsuper.net/ an Internet Direct company | +1.514.281.7500, x233 (phone) +1.514.281.6599 (fax) | http://www.dsuper.net/~bmilekic/| _| On Sat, 31 Jul 1999, Alex Povolotsky wrote: Hello! I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. I have a hack that requires to change libc to make getpwent access not only /etc/master.passwd, but also some mySQL database, but it is hard-to-rebuild and overall dirty hack. Do not ask me to RTFM on PAM, for PAM does not allow me to add users not mentioned in passwd. As far as I understand, LDAP is rather bulky and suited to X.500 integration, and that is not what I want. Any suggestions, anyone? Alex. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Hi Alex, Alex Povolotsky tark...@asteroid.svib.ru wrote: I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. cucipop is fairly simple to modify (it's well structured for change) and I've managed to hack in bits of merit radius client code into it once or twice -- to authenticate POP clients from the local radius server... sendmail local delivery was a pain, I ended up fudging that with an additional aliases file mapping names to files (ugh!)... Cheers Leigh -- | By the time they had diminished | Leigh Hart, h...@dotat.com | | from 50 to 8, the other dwarves | CCNA - http://www.cisco.com/ | | began to suspect 'Hungry' ... | GPO Box 487 Adelaide SA 5001 | | -- Gary Larson, The Far Side | http://www.dotat.com/hart/ | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Oh yeah, and check out the jail code (sections 2 and 4, I *think* -CURRENT only). - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
On Sat, 31 Jul 1999, Alex Povolotsky wrote: I'm going to implement a large mail-box, with several hundreds of mail-only users. They should never access anything besides their POP3 mailboxes and change password via (SSLed) web interface. So, I don't want to add all of them to /etc/passwd. The easiest way I can think of would be to add them to /etc/passwd and set their shell and home dir to /nonexistant. Ideally you wouldn't be running any other daemons, so there'd be no real way for them to access files; but the stock ftpd, as well as sshd offer ways to disable access to specific users. Dealing with real users IMO is quite a bit less hackish. - alex You wear guilt, like shackles on your feet, Like a halo in reverse - Depeche Mode To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Solution for mail pseudo-users?
Alex Povolotsky wrote: 37a30852.20e5a...@bellatlantic.netSergey Babkin writes: Any suggestions, anyone? Modify the POP daemon to use your mySQL database in addition to getpwent ? That seems to be the easiest way that should not break anything else. And modify sendmail to throw off mail for nonexistent users? You can unload the user list from mySQL into a Berkeley db file and modify /etc/sendmail.cf to route the mail for the users listed in this file to a special delivery agent. And this special delivery agent would be a quite straightforward modification of /usr/libexec/mail.local. A variation of this would be to modify mail.local to add the data from mySQL database to getpwent, just like POP3 does, and instruct sendmail to process the mail for the extra users by mail.local. -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
