Anders Brander writes: > > 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. :) > 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. :) > Another possibility it will open, is the users who administer their mail > with shell-access (mailinglists, other things) could have access to > their vpopmail-databases and do with them as they like. You may have users like that. We have one user like that (me) and one user who thinks he is like that (my boss, who gets more pointy-haired with each passing day). This is one of the reasons vpopmail goes in so many different directions - it has to attempt to cover so many 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. > 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. > 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... > 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. > It may turn out to be the best solution - but i see lots of problems > with this solution. > 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 can't do authentication without a username and password. :) And that they would return at least one value. Obviously, any tool which reads userinfo has to return several values. But although it is possible to program such things insecurely and vulnerable to buffer overflox exploits, it is also possible to program them securely (unless Ken Thompson has hacked your C compiler, in which case you're screwed whatever you do). Provided these tools are kept SMALL then a code audit will catch any currently-known vulnerabilities like people allocating a fixed amount of static memory to hold a string which the user determines. And provided they're small, the chance that the C compiler introduces an as-yet unknown vulnerability is also small. 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. 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. -- Paul Allen Softflare Support
