Hi, Phew, this mail is getting longer and longer...
On Fri, 2003-09-12 at 04:23, Paul L. Allen wrote: > > > It could get rather unwieldy if you use MySQL for other things. > > Why? > Just a gut feeling that if you have many MySQL users for one purpose > and many more MySQL users who are there purely as a fiddle to allow > vpopmail to work then it could make life difficult to distinguish the > two. But I am easily confused. :) IMHO it's the correct (tm) way to do things. It's not just a fiddle, it's the best solution. I would say that the setuid-thing is a fiddle. > > It could easily be done with vadddomain, the user must pre-exist as it > > is now, vopmail just have to create the .mysqlpass-file or whatever it > > is called. Or am i missing something here? > Yes, you're missing me having to do two things instead of one. There > are ways of setting up vpopmail so that if I add a system user then they > automatically get mail. Yes, those solutions are non-standard hacks > using custom scripts but they exist. My work is finished after I do > useradd. Every time I have to do two things to add a user it not only > increases my workload it increases the chance that I do one but not the > other. As I think I may have said, I am easily confused. :) I think we confused eachother, we were talking about two different cases. I: When domain.tld is given a systemuser for their mail. You: When systemusers needed personal mail. - and now i can see the trouble ahead, but not that much trouble. [snip, user types] > different usage patterns. For instance, the quota stuff is essential > for a company wanting to offer a hotmail/yahoo/whatever service. For > us it gets in the way of us billing people extra for going over their > allotted usage. OT: We use the billing-model too :) But we also have skilled users, the kind that just sends you the conf-file, the kind that writes their own zone data. The kind that never calls, and when they do - you KNOW that they have a very good reason to do so. > > They could make ther own internal php-tools for example, > You let your users play with PHP? I hope you have something that > emulates suexec so you have some rudimentary protection against them > using it to explore the filesystem. Then again, in your environment > it may not matter. In ours PHP without an suexec equivalent would > be a disaster. PHP, without modifications, is a security nightmare for > any user who wishes to have a web interface create or modify files. > When you have to make directories world-writeable or writeable by > the UID of the HTTP server then you have a security nightmare. Let's leave PHP-(in)security out of this. > > setuid programs can be a very nice solution to many problems, but i > > think that we should consider the possibility of just using standard > > filelevel security. That's something that has been audited and proven > > for years. > Ummm, I don't trust ANYTHING. I remember when the third edition of the > Camel book came out reading of many attacks that had not been mentioned > in the 2nd edition because they had not been known then but had always > been present. How about the race hazard when executing shell > or perl scripts (these days largely eliminated)? How about the many > race hazards suexec is vulnerable to (I know of no exploits and the > checks it does are better than no checks at all)? As we both know, the > only way to secure your computer is to ensure it has no connections to > the outside world and you are the only one who has physical access - as > soon as you relax those constraints you are taking risks. The question > is: is this particular solution playing Russian Roulette with 5 out of the > 6 chambers loaded or only 1 of the 6 chambers loaded... Very well said about the roulette thing. > > It's a great idea to have several small tools to do tasks, my point was > > just that it's not enough to return 0 or 1 (or 57). > Again, I was illustrating how the simple case of password authentication > (without APOP) would go. The idea was to establish the general model > for doing this sort of thing with setgid cleanly. I was illustrating that it could quickly get hairy, when arguments have to be passing to/from these tools. > > Mainly the passing of arguments to/from these tools. If it were just > > TRUE/FALSE-returns i would be all for it - well, almost ;-). > I always envisaged that these tools would be passed arguments - you [snip] I think we already adressed this - and agreed... > Set-id code is not without known hazards and there may be unknown > hazards. I was addressing the question of whether there was any > way of doing things relatively securely with set-id code. I don't > think the risks are significantly higher than with qmail set-id code > and I think they are vastly lower than with sendmail's monolithic, > gigantic block of set-id code which has been exploited many times. Ohh boy i'm glad we are on a qmail-oriented list, elsewise we would have the great sendmail-flamefest now :) > I really don't know what the best solution is, and to some extent > don't care because I don't use MySQL with vpopmail. To me it was > an academic exercise of finding a relatively low-risk set-id > solution. I care alot, i have a mysql setup with different userids. But please continue your academic exercises regarding to this issue! /Anders
