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.


> > 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 ;-).


Reply via email to