Hi, On Fri, 2003-09-12 at 03:16, Paul L. Allen wrote: > > If you add a special group to every user you are back where you started. > I didn't say it was a good solution. I said it was a solution. Compared > to that, a lot of the alternatives look good.
Agree, alternatives are better. > > I can't see what's wrong with a mysql user per system user. That would > > be really clean and effective. > It could get rather unwieldy if you use MySQL for other things. Why? > > If the admistrative tools is integrated into vpopmail, i fail to > > see any troble ahead (user/admin-vice). > I can see one. I set up a system user. Who wants e-mail. So then > I have to use another tool to add that user to vpopmail. 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? 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. They could make ther own internal php-tools for example, their own weird scripting. I think maybe this could be a big "selling point". > > It would completely remove any use for any setuid/setgid-hacks. > That is the one advantage I see to it. Whether or not one views that > advantage as compelling is another matter. 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. > > > 3) A very small utility that is setgid vpsql. It does the following > > > when passed a username and password to verify. > > You will also need small tools to do all other sorts of operations, > > quota, valias and so on. > I did mention those at the end. And even said that I preferred several > small tools to one large one that use switches to decide what it did > because that would mean more code and a harder time auditing it. 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). > > It's not as simple as that, think about APOP authentication... > I don't have need of APOP so I didn't think about it. I was trying > to establish the general principle for doing it setgid with minimal > risks. I think something (well, several somethings) along those lines > would be feasible without opening up vulnerabilities. None of us like > set-id and try to avoid it, but there are times when it is better than > the alternatives (if sufficient care is taken). Compared to the major > hunk of setuid code that is sendmail and which a lot of systems run, > this ought to be far less likely to be exploited. It's not the only > solution and it may turn out not to be the best solution, but at least > it's there for consideration (and possible improvement). 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 ;-). /Anders
