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
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
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
I care alot, i have a mysql setup with different userids. But please
continue your academic exercises regarding to this issue!