raw TCP communication with mysql server

[sourceninja]

Originally posted by: RedSquirrel
Licensing is another reason I want to go away from libraries. If I code everything myself then no need to worry about any kind of restrictions, or companies going under, etc. Self sufficient FTW.

Ummm, if you write your own library to access mysql and mysql goes out of business you are still going to have to rewrite everything to use a new database....

 

[Red Squirrel]

I'm talking of the one who wrote the library. Lot of open source projects tend to just vanish in thin air. Though it does seem mysql++ are quite up to date, but just saying, if I code my own header file that does everything I'm not depending on a 3rd party, and I'm making my program that much easier to deploy (I just include the .h with rest of my files). It would also be very fast as it's not going through any kind of wrapers, though that's probably not a huge issue as the difference is probably way too small.

So besides the point that it's a bad idea, anywhere I can find these resources? That's all I really need, an official packet representation of the mysql protocol. I'm sure one must exist somewhere, as someone needed it to write the existing libraries.

Basically this is what I'm looking for: http://kec.cz/tartaros/steamen....kairtech.com/uo/info/ But for Mysql.

 

[sourceninja]

You realize that if a developer drops an open source project, you are free to pick up the source and maintain it yourself right? And you will not have to give the source to anyone you don't give your application to. It also appears the C++ mysql connector is maintained by msyql and the c++ api is maintained by someone close to mysql. It's not going anywhere. In fact the C++ api is LGPL, so you can distribute it with your application without making your app open source.

In any case, good luck finding what you are looking for. And good luck reinventing the wheel.

 

[Nothinman]

That's all I really need, an official packet representation of the mysql protocol. I'm sure one must exist somewhere, as someone needed it to write the existing libraries.

I already posted a link to the protocol...

 

[Red Squirrel]

So that's the official latest, and fully updated? I expected more like a RFC page but if that's official then it will more then do.

I will probably start on this shortly. Every time I need to get a mysql++ app to compile on a different system I have to spend hours getting mysql++ to work properly on that system and usually have to change my program around too. The source code and compile script is not compatible from machine to machine because of how stuff in linux just gets thrown all over and there is no consistency from distro to distro. Some programs I have to do #include<mysql++> others it's mysql/mysql++, then the compile parameter which is super long changes all the time, other times I need to do a bunch of symlinks for the program to even run... way too much trouble. If the wheel has 40 different sizes of screws and other weird things with hardly no instructions, sometimes it *IS* easier to just reinvent it. In the end, I will save lot of time, and so will anybody else wanting to compile and use my app, as it will be a simple .h file that does everything, no complicated libraries and crap.


Also, how often does the mysql protocol change? Is this something that happens a lot, or is it pretty much set in stone, like ftp, http etc?

I've been wrestling for 5 hours trying to get mysql++ to work in FC9 and I've given up. Tomorrow I'll just start coding the library. I can probably do it faster then it takes to figure out how to get it working on every distro + document all the steps for each distro, because of course, they'll all be totally different and inconsistent.

 

[Nothinman]

So that's the official latest, and fully updated? I expected more like a RFC page but if that's official then it will more then do.

Dunno, but it's hosted at mysql.com so it's at least semi-official.

Every time I need to get a mysql++ app to compile on a different system I have to spend hours getting mysql++ to work properly on that system and usually have to change my program around too. The source code and compile script is not compatible from machine to machine because of how stuff in linux just gets thrown all over and there is no consistency from distro to distro. Some programs I have to do #include<mysql++> others it's mysql/mysql++, then the compile parameter which is super long changes all the time

That's what autoconf, automake, etc were built for.

If the wheel has 40 different sizes of screws and other weird things with hardly no instructions, sometimes it *IS* easier to just reinvent it.

But if everyone else already has a wheel why would they want to you use yours too? I know that whenever I see an app that even includes a copy of another library I question it and look for alternatives. If I saw an app that said it includes it's own implementation of something else for no good reason (and your posted reasons aren't good) I'd do everything in my power to avoid using it.

In the end, I will save lot of time, and so will anybody else wanting to compile and use my app, as it will be a simple .h file that does everything, no complicated libraries and crap.

And it'll waste a ton of time because every time a MySQL security update is put out your users will have to wonder whether or not your code is affected by the same problem. And you'll have to watch MySQL development closer to make sure your code still works and isn't exploitable by whatever problems the MySQL people run into.

Also, how often does the mysql protocol change? Is this something that happens a lot, or is it pretty much set in stone, like ftp, http etc?

Hard to say since I don't watch MySQL developemt but from the beginning of that document it's at least changed between 4.0, 4.1 and 5.0.

 

[Red Squirrel]

Security updates are a non issue. My class is only to connect to a mysql DB, it is not a replacement for Mysql. So if mysql has a security flaw they are the ones that have to fix it either way. It's like if there's a security issue in Apache, it does not matter if you use IE or firefox or opera and neither do those browsers need any kind of update, it's apache that needs an update.

The protocol seems easy enough to implement. I can probably get at least a basic class done easily. I don't really need any of the more advanced features like the gzip compression. Later on I can look at implimenting a huffman tree or whatever is needed for gzip, but it's my last concern. Most if all implementations run locally. It will just be awesome to have a class that works no matter what, and on any distro, without any dependencies. It will even work on Windows. Zero wrestling.

 

[Crusty]

Originally posted by: RedSquirrel
Security updates are a non issue. My class is only to connect to a mysql DB, it is not a replacement for Mysql. So if mysql has a security flaw they are the ones that have to fix it either way. It's like if there's a security issue in Apache, it does not matter if you use IE or firefox or opera and neither do those browsers need any kind of update, it's apache that needs an update.

The protocol seems easy enough to implement. I can probably get at least a basic class done easily. I don't really need any of the more advanced features like the gzip compression. Later on I can look at implimenting a huffman tree or whatever is needed for gzip, but it's my last concern. Most if all implementations run locally. It will just be awesome to have a class that works no matter what, and on any distro, without any dependencies. It will even work on Windows. Zero wrestling.

I don't think you really understand anything you are talking about. You are implementing the mysql protocol. That would be akin to you writing your own browser engine that can render html. Are you saying that the browser would be immune to security flaws in the HTML protocol because you implemented it and it's not written by teams of programmers?

On top of that, not only do you have to worry about security holes in the protocol itself, but your code has to deal with being secure itself. There's no point in writing your class if someone can send it a malformed packet and have it crash, or better yet exploit a buffer overflow in your code to get a shell on your servers.

Are you planning on taking this approach with every piece of code you write? If so, you really need to rethink your approach...

You are far better off learning how to use the right tools to do all the heavy lifting for you. Programmers by nature are lazy, it's always about getting the most done with the least amount of effort. Learn the tools once, use them forever or don't learn the tools and be stuck forever.

A bit of real world advice too, knowing how to implement the mysql protocol will only get you somewhere in niche markets, while knowing how to code a general purpose Linux application using general purpose tools will get you a LOT farther along. You need to have a solid foundation of the standard tools in Linux to write a solid application.

Saying something doesn't work right because you can't be bothered to put in the time to learn how to use it is downright idiotic. There are specific tools, many of which Nothinman pointed out, to do exactly what you are having problems with.... learn them, love them, use them.

 

[Nothinman]

Security updates are a non issue. My class is only to connect to a mysql DB, it is not a replacement for Mysql.

Not at all, if I can trick your client into doing something that exploits a MySQL protocol vulnerability I can execute code as whatever user your daemon runs as. You absolutely have to pay attention to MySQL protocol problems.

It's like if there's a security issue in Apache, it does not matter if you use IE or firefox or opera and neither do those browsers need any kind of update, it's apache that needs an update.

Your analogy is so wrong it's not funny. Following your analogy we're not talking about IE or Apache we're talking about HTTP, and if your client implements it's protcol with a specific bug then you're just as vulnerable as everyone else.

It will just be awesome to have a class that works no matter what, and on any distro, without any dependencies. It will even work on Windows. Zero wrestling.

Or you could spend a day learning autoconf and do it the right way. But I really doubt you'll do that until after your implementation fails miserably...

 

[sourceninja]

I had already given up on this thread.

 

[Red Squirrel]

Maybe I'm missing something but how would one manage to exploit a program using an existing implementation of a protocol? Unless there's a flaw in the protocol itself but then it does not really matter how the program is coded, it would be a design flaw in the actual protocol. For example, passwords being sent in clear text is a security risk for FTP and other protocols, but that's not an issue with the program, it's an issue with the protocol.

Not to mention this is a client, and not a server, people can't actually connect to it and try to send malformed packets or something. If I'm missing something please tell me so I can take it into consideration.

I'll start on this shortly. I found some bugs in my sockets implementation so I fixed them first. The beauty of a set of custom libraries is if there's an issue I can fix it once, and only once and then recompile any of my apps that depend on it. Zero fighting when moving it to another distro, either.

 

[Nothinman]

Maybe I'm missing something but how would one manage to exploit a program using an existing implementation of a protocol? Unless there's a flaw in the protocol itself but then it does not really matter how the program is coded, it would be a design flaw in the actual protocol. For example, passwords being sent in clear text is a security risk for FTP and other protocols, but that's not an issue with the program, it's an issue with the protocol.

Depends on what the problem is. Plain-text passwords in FTP are problem but they're also part of the implementation and can't be changed without making incompatible changes to the protcol. But there can be a problem with one implementation of the protocol that doesn't affect others. Since you're looking at SQL you'll no doubt have to deal with arbitrary length strings for SQL commands. How you deal with those buffers is up to you and dealing with them poorly can result in exploitable code.

Not to mention this is a client, and not a server, people can't actually connect to it and try to send malformed packets or something. If I'm missing something please tell me so I can take it into consideration.

You're still talking to an untrustable source whether you initiate the connection or not so you have to be extremely careful when handling the data given to you. And if they can connect to the database or somehow trick your client into putting malformed data into the database then you have to worry about that data coming back to your client.

The beauty of a set of custom libraries is if there's an issue I can fix it once, and only once and then recompile any of my apps that depend on it. Zero fighting when moving it to another distro, either.

That's the beauty of shared libraries in general, you'd get the same benefits from the ones already installed on your system if you'd learn how to use the build tools properly.