Anders Brander writes:
> > It could get rather unwieldy if you use MySQL for other things.
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. :)
> 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. :)
> 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.
You may have users like that. We have one user like that (me) and one
user who thinks he is like that (my boss, who gets more pointy-haired
with each passing day). This is one of the reasons vpopmail goes in
so many different directions - it has to attempt to cover so many
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
> 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.
> 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...
> 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.
> 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 ;-).
I always envisaged that these tools would be passed arguments - you
can't do authentication without a username and password. :) And that they
would return at least one value. Obviously, any tool which reads
userinfo has to return several values. But although it is possible
to program such things insecurely and vulnerable to buffer overflox
exploits, it is also possible to program them securely (unless Ken
Thompson has hacked your C compiler, in which case you're screwed
whatever you do). Provided these tools are kept SMALL then a code
audit will catch any currently-known vulnerabilities like people
allocating a fixed amount of static memory to hold a string which
the user determines. And provided they're small, the chance that
the C compiler introduces an as-yet unknown vulnerability is also
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.
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