Hi Anders Anders Brander writes:
> 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. I think which way you regard as a fiddle depends very much upon what you do on your system. > I think we confused eachother, we were talking about two different > cases. > I: When domain.tld is given a systemuser for their mail. Ah, we don't do that. We probably could, since we have to give them a system user to FTP their web site, but why bother when vpopmail lets you get away with a single user? Oh, unless you're using a PHP webmail interface, in which case you'd be forced into giving each domain a separate system user to prevent people reading mail for other domains. Hmmm, but unless you have an equivalent of suexec for PHP then you'd have to leave directories writeable by the httpd user so that people can delete mail, which means that a malicious user could delete mail for other domains (the malicious user would have to guess at filenames and it would take many guesses to stand a chance of hitting one, but it's your CPU cycles he's burning not his). I know you asked me to leave PHP insecurity out of this, but I'm guessing that the reason you have a system user for each domain is a fiddle to work around PHP insecurity in the first place. > You: When systemusers needed personal mail. > - and now i can see the trouble ahead, but not that much trouble. The trouble is that vpopmail can be used in so many different ways. > 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. Our users are almost all technically incompetent. We expect them to call and blame us for what turns out to be their own problem. We charge them for that. > I was illustrating that it could quickly get hairy, when arguments have > to be passing to/from these tools. I think argument and value passing is reasonably well understood, relatively easy to code and the methods of avoiding buffer overflows known if not always widely applied. Provided the utilities are restricted to reading and writing the database it should be easy to ensure there are no known exploitable holes. > Ohh boy i'm glad we are on a qmail-oriented list, elsewise we would have > the great sendmail-flamefest now :) Indeed. But it's a valid point. Given the number of systems running sendmail which has had many exploits, a few very small pieces of well-audited setgid code pose far less of a risk. Particularly when sendmail is setuid root and the code I'm proposing would be setgid to a group used for no other purpose. Sendmail has bullets in 5 of the chambers and people play Russian Roulette with it all the time yet surprisingly few are killed. -- Paul Allen Softflare Support
