Not sure what a footgun is, but this approach works and has worked well for MySQL users for years. It's not about "admin functions" or anything else. It's about providing for the ability to provide distinct privileges depending on whether the user connects locally or remotely (without having to use stored procedures or have multiple users).
"In PostgreSQL if you really need to do this, I you can use security definer stored procedures which could check for arbitrary other criteria and deny permission on that basis."
You can do the same in MySQL. But, point being, you don't need to get complex to accomplish something as simple as separate privileges for the same user connecting from different hosts.
Yes, indeed, different privileges. For instance, it's very common for me to have a user with CREATE/INDEX/DROP permissions on localhost, but for security reasons, restrict the privileges to SELECT for the same user connecting via a remote host to do some reporting functions...hope that makes sense.
"In PostgreSQL, you just set it up to specify that cetain user and/or host combinations require a different form of authentication."
I see. Although, I guess I'm talking less about authentication and more about authorization/privileges... I don't see too much of a need to have separate authentication mechanisms in the work I do, but, as always, different needs for different apps, eh?:)
Cheers!
-jay
"It would be much nicer to have a nice system like PostgreSQL has, where you can assign various hosts to auth methods, but usernames are unique."
So, if you had a single user, but wanted different security depending on where they connect from (local or remote), you need two usernames? In MySQL it's simple and easy to set up that common scenario.
As for various auth methods, there are plans for authentication plugins to allow it, but as far as changing the core system, I would prefer to keep it as simple and easy as possible, with complexity provided through plugins. See here:
This is totally incorrect. Please don't spread FUD. MySQL has not stopped supporting any distro, or stopped providing binaries to the community, or anything of the sort. Please see Kaj Arnö's blog post here (http://www.planetmysql.org/kaj/?p=84) for *accurate* information, and feel free to contact the MySQL community team (community at mysql dot com) if you have any questions on this. Please, don't let the FUD continue to spread. Check the facts and ask us for information if you're unsure.
Cheers,
Jay Pipes
Community Relations Manager, North America, MySQL
jay at mysql dot com
You are proving that you don't really understand the technology or the business behind MySQL and are fine with throwing your lot behind myths that have been propogated for a long time now. You say:
Revert back to telling would-be users that ACID, stored procedures, etc. are unimportant and that they belong in client code?
Stored procedures have nothing to do with Oracle, InnoDB, or anything else here. They exist above the storage engine level at the language level and work with any storage engine, InnoDB or otherwise, as do triggers, views, functions, events, etc.
If you have other plans, by all means let us know! In the mean time, the thought of building business logic on MySQL is growing scarier by the month.
Innobase/Oracle is one of several storage engines that have/will have ACID-compliant transactions. PBXT, SolidDB, the upcoming Falcon storage engine, and MyISAM++ all have or will have ACID-compliant features. So, yes, we do have a "fallback plan" and have for a long time now.
And one free bit of advice: distance yourself from SCO! That affiliation by itself is an enormous dealbreaker for a lot of people.
Thanks very much for this piece of advice. I hadn't heard that before. Seriously, I don't know why I bother even responding on/. anymore. It's just a breeding ground for dogmatic idealogues to flame-bait.
Sorry to rain on your parade of myths, but this:
"availability, I can't see a single reason to use MySQL these days. All of their cool features are owned by their competitors, and they're starting to pull desperate financing tricks like whittling away tech support and partnering with SCO"
is nowhere near true. If by cool features, you mean InnoDB, sure Oracle does own InnoDB, but the largest growth MySQL has seen is in the area of scale-out replication, telecom's usage of MySQL Cluster, and in the expansion of pluggable storage engine partners. MySQL Replication and MySQL's NdbCluster aren't owned by anyone other than MySQL, and the growth in storage engine partners shows you that a lot of companies believe MySQL's growth in the commodity scale-out market is because of something substantial, not just from a "whittling away of tech support".
Contrast this to GreenPlum owning the (not open source) Bizgres MPP clustering project, to EnterpriseDB's (not open source) Replication Server "fork".
Please. Quit propogating complete fabrications.
If you want to argue that PostgreSQL is more "Oracle-like" in its SQL-implementation, fine. But don't troll away with flames that don't have a lick of truth in them.
If the contributor did not assign us copyright, we would not legally (in the US), be able to include their code in ours. AFIAK, US copyright law says that you do not have the right to publish another person's work unless you have either bought or been assigned the rights to that work. Our general counsel would know the answer to this question better than I, but that's as far as I understand it.
In addition, you say that "you demand that contributors assign all rights, so that you can distribute an alternative license, including this code, for a fee." We charge for our packaging and support, not our source code. This is part of the reason that it is explained in the CLA that part of MySQL's responsibility is the maintainership of your contributed code.
I'm not quite sure I understand what you mean by "what degree that company nature dilutes the GPL". Could you be a bit more specific?
Thanks!
The Contributors License Agreement (copyright assignment) is necessary so that MySQL does not violate US copyright laws. That's really about it.
As for whether we are open source, you will hear various parties argue one way or the other, usually coming down to our licensing choice or the fact that 99.9% of the code is developed internally. The fact is, though, that we're committed to open source ideals of access to source code and the freedom to modify and distribute the source code, and we will remain committed to those ideals.
I suppose people in general need to wake up and understand that MySQL is a *company*, too. That company provides jobs for many, many open source developers, and the company provides a quality, open source product to the larger community. The larger we grow our business base, the more we can contribute back to the open source community. Simple as that, at least in my mind.
- Jay Pipes Community Relations Manager, North America, MySQL, Inc.
Yes, unfortunately, my name really is Jay Pipes:) I suppose me being a programmer is better than me going into the plumbing business, which unfortunately my father was in for 30 years. No joke.
Slashdot Mirror
Not sure what a footgun is, but this approach works and has worked well for MySQL users for years. It's not about "admin functions" or anything else. It's about providing for the ability to provide distinct privileges depending on whether the user connects locally or remotely (without having to use stored procedures or have multiple users).
"In PostgreSQL if you really need to do this, I you can use security definer stored procedures which could check for arbitrary other criteria and deny permission on that basis."
You can do the same in MySQL. But, point being, you don't need to get complex to accomplish something as simple as separate privileges for the same user connecting from different hosts.
Yes, indeed, different privileges. For instance, it's very common for me to have a user with CREATE/INDEX/DROP permissions on localhost, but for security reasons, restrict the privileges to SELECT for the same user connecting via a remote host to do some reporting functions...hope that makes sense. "In PostgreSQL, you just set it up to specify that cetain user and/or host combinations require a different form of authentication." I see. Although, I guess I'm talking less about authentication and more about authorization/privileges... I don't see too much of a need to have separate authentication mechanisms in the work I do, but, as always, different needs for different apps, eh? :)
Cheers!
-jay
"It would be much nicer to have a nice system like PostgreSQL has, where you can assign various hosts to auth methods, but usernames are unique."
So, if you had a single user, but wanted different security depending on where they connect from (local or remote), you need two usernames? In MySQL it's simple and easy to set up that common scenario.
As for various auth methods, there are plans for authentication plugins to allow it, but as far as changing the core system, I would prefer to keep it as simple and easy as possible, with complexity provided through plugins. See here:
http://forge.mysql.com/wiki/PluggableAuthenticationSupport
http://forge.mysql.com/wiki/PluggableAuthorizationSupport
Cheers,
j
This is totally incorrect. Please don't spread FUD. MySQL has not stopped supporting any distro, or stopped providing binaries to the community, or anything of the sort. Please see Kaj Arnö's blog post here (http://www.planetmysql.org/kaj/?p=84) for *accurate* information, and feel free to contact the MySQL community team (community at mysql dot com) if you have any questions on this. Please, don't let the FUD continue to spread. Check the facts and ask us for information if you're unsure. Cheers, Jay Pipes Community Relations Manager, North America, MySQL jay at mysql dot com
Sorry to rain on your parade of myths, but this: "availability, I can't see a single reason to use MySQL these days. All of their cool features are owned by their competitors, and they're starting to pull desperate financing tricks like whittling away tech support and partnering with SCO" is nowhere near true. If by cool features, you mean InnoDB, sure Oracle does own InnoDB, but the largest growth MySQL has seen is in the area of scale-out replication, telecom's usage of MySQL Cluster, and in the expansion of pluggable storage engine partners. MySQL Replication and MySQL's NdbCluster aren't owned by anyone other than MySQL, and the growth in storage engine partners shows you that a lot of companies believe MySQL's growth in the commodity scale-out market is because of something substantial, not just from a "whittling away of tech support". Contrast this to GreenPlum owning the (not open source) Bizgres MPP clustering project, to EnterpriseDB's (not open source) Replication Server "fork". Please. Quit propogating complete fabrications. If you want to argue that PostgreSQL is more "Oracle-like" in its SQL-implementation, fine. But don't troll away with flames that don't have a lick of truth in them.
Hmm, you must be referring to Marten's interview from before *2001*, then? ;)
If the contributor did not assign us copyright, we would not legally (in the US), be able to include their code in ours. AFIAK, US copyright law says that you do not have the right to publish another person's work unless you have either bought or been assigned the rights to that work. Our general counsel would know the answer to this question better than I, but that's as far as I understand it. In addition, you say that "you demand that contributors assign all rights, so that you can distribute an alternative license, including this code, for a fee." We charge for our packaging and support, not our source code. This is part of the reason that it is explained in the CLA that part of MySQL's responsibility is the maintainership of your contributed code. I'm not quite sure I understand what you mean by "what degree that company nature dilutes the GPL". Could you be a bit more specific? Thanks!
The Contributors License Agreement (copyright assignment) is necessary so that MySQL does not violate US copyright laws. That's really about it.
As for whether we are open source, you will hear various parties argue one way or the other, usually coming down to our licensing choice or the fact that 99.9% of the code is developed internally. The fact is, though, that we're committed to open source ideals of access to source code and the freedom to modify and distribute the source code, and we will remain committed to those ideals.
I suppose people in general need to wake up and understand that MySQL is a *company*, too. That company provides jobs for many, many open source developers, and the company provides a quality, open source product to the larger community. The larger we grow our business base, the more we can contribute back to the open source community. Simple as that, at least in my mind.
- Jay Pipes
Community Relations Manager, North America, MySQL, Inc.
Yes, unfortunately, my name really is Jay Pipes :) I suppose me being a programmer is better than me going into the plumbing business, which unfortunately my father was in for 30 years. No joke.