On Sun, 2006-06-18 at 14:08 +0200, Marc Dirix wrote: > As every good administrator, don't change a working system unless you > have to, and > regularly check if things are still ok. Administrating is not a job > of only creating new applications, improving application or spending > your bosses money, it is a job of keeping and maintaining service.
I agree with this completely. > > One day, I took over for a customer who's previous admins had thought > > rsync was a good way to backup their mysql database. One day they came > > in and all the databases were empty. Can you guess why? > > > > Does your backup system protect against this failure? > > > > *My* backups do, as I mentioned. Are you sure? as I mentioned? You cut out a bunch of my failure points and responded that your backup policy was safe against one of them- does this mean it's no good against the others? > Although it is everyones choice to use a database, but i seriously > recommend against MySQL, > it's faundation is not based on data integrity and security. And neither is DBMail. You may misunderstand everything else I've said, but understand me here: I'm suggesting that DBMail make data integrity and security a focus. > > The administrator that you're talking about obviously equates security > > with lack-of-breaches. That's not what we're talking about. > > > > How do you mean this, please explain. Many folk- even here on this list have said "don't cry wolf" (don't say there's a security hole if you don't know exactly where it is), or that lack of security is only through _proof_ of lack of security- to me, this sounds an awful lot like they expect security to be a measure of vulnerabilities over usage. This is the benchmark Microsoft likes to use, and I think that it's unfortunate because it doesn't actually create trust, or knowledge of how to be proactive. > > We're talking about security as in the kind that the rest of the world > > uses- as in demonstrating risk, privilege possibility, attack vectors, > > and knowledge of how DBMail interacts with the system, the users, and > > the environment. > > > > All nice words, but they all mean the same. They _don't_ mean the same thing. A security firm would get sued all to hell if they said "see, your house is secure because there's a lock on the door." Instead, they say: "There is a lock on all your doors. These will do well against some kinds of casual attacks, but not by themselves: For example, putting the key to these doors under a flower pot will negate much-if not all of the security that these locks can provide." But here, in systems, it's _expected_ that software be secure. And yet, most software either makes no mention of security or simply says "there haven't been any vulnerabilities yet". I don't know how to be any clearer about this: Just because nobody has used the key under your flower pot doesn't mean you're secure. > > I'd like to recommend that we _not_ avoid the issue. Not because _I_ > > need DBMail to be secure- as I said, I'm already fine- it's the > > rest of > > you I'm worried about: The ones that think security breaches are what > > you've got to worry about. > > Sometimes it seems you think you're the best administrator, and the > rest is just a bunch of kids. I'm offering _reasons_ behind my thinking that aren't getting refuted by anything except dogma. Did you even bother to read this thread? Or are you still mad that I think code duplication is wrong? _I_ am concerned about security- and I am concerned about DBMail. I set up a method by which I can reconcile the two, and _I_ suggested that since the big bad security risk genie was popped from its bottle, DBMail should either (a) do an extension of what I do [privilege separation so it isn't an issue], or (b) do something really really hard [audit]. > That isn't always a nice way to interact with people, people tend to > stop considering your answers. Are you still mad that you daemonize without knowing why? > There are as many viewpoints to subjects as there are people, Are you saying that you really believe that DBMail doesn't need an audit? Or are you saying that privilege separation is a bad idea? Or are you saying that security isn't important as long as your backup policy works against one of the failures I mentioned? Or are you saying that security isn't important until vulnerabilities happen? What exactly do you mean? If you want me to merely respond to each thing you say, I'll continue to do so, but if you have a point, I'd love to know what it is. > although for some people the viewpoints differ less, so they can join > to create mighty projects, as is with MySQL/ PostgreSQL, > and as have Paul and Aaron. So what you're telling me is that you think only developers of dbmail should be weighing in on the subject of dbmail's security? > > -- > > Internet Connection High Quality Web Hosting > > http://www.internetconnection.net/ > > > > I really dislike adds send to an opensource mailinglist! I've noticed there are lots of things you don't like, but you don't say why. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
