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
> solution.

I care alot, i have a mysql setup with different userids. But please
continue your academic exercises regarding to this issue!


Reply via email to