DEFINITION OF ANY ROUTINE.

The problem was that having the SELECT privilege any column of the
mysql.proc table by mistake allowed the user to see the definition
of all routines (using SHOW CREATE PROCEDURE/FUNCTION and SHOW
PROCEDURE/FUNCTION CODE).

This patch fixes the problem by making sure that those commands
are only allowed if the user has the SELECT privilege on the
mysql.proc table itself.

Test case added to sp-security.test.

Didn't build on Solaris.

The LGPL license is used in some legacy code, and to
adhere to current licensing polity, we remove those
files that are no longer used, and reorganize the
remaining LGPL code so it will be GPL licensed from
now on.

Note:  This patch only removed LGPL licensed files
       in MySQL 5.0, and is the first of a set of
       patches to remove LGPL from all trees.
       (See Bug# 11840513 for details)

Reverse DNS lookup of "localhost" returns "broadcasthost" on Snow Leopard (Mac), and NULL on most others.
Simply ignore the output, as this is not an essential part of UDF testing.

on behalf of Kent: Include the README into the binary packages

privileges".

The first problem was that DROP USER didn't properly remove privileges 
on stored functions from in-memory structures. So the dropped user
could have called stored functions on which he had privileges before
being dropped while his connection was still around.
Even worse if a new user with the same name was created he would
inherit privileges on stored functions from the dropped user.
Similar thing happened with old user name and function privileges
during RENAME USER.

This problem stemmed from the fact that the handle_grant_data() function
which handled DROP/RENAME USER didn't take any measures to update
in-memory hash with information about function privileges after
updating them on disk.

This patch solves this problem by adding code doing just that.

The second problem was that RENAME USER didn't properly update in-memory
structures describing table-level privileges and privileges on stored 
procedures. As result such privileges could have been lost after a rename
(i.e. not associated with the new name of user) and inherited by a new
user with the same name as the old name of the original user.

This problem was caused by code handling RENAME USER in
handle_grant_struct() which [sic!]:
a) tried to update wrong (tables) hash when updating stored procedure
   privileges for new user name.
b) passed wrong arguments to function performing the hash update and
   didn't take into account the way in which such update could have
   changed the order of the hash elements.

This patch solves this problem by ensuring that a) the correct hash
is updated, b) correct arguments are used for the hash_update()
function and c) we take into account possible changes in the order
of hash elements.

Bug #55755 : Date STD variable signness breaks server on FreeBSD and OpenBSD

* Added a check to configure on the size of time_t
* Created a macro to check for a valid time_t that is safe to use with datetime 
  functions and store in TIMESTAMP columns.
* Used the macro consistently instead of the ad-hoc checks introduced by 52315
* Fixed compliation warnings on platforms where the size of time_t is smaller than
  the size of a long (e.g. OpenBSD 4.8 64 amd64).

Bug #52315: utc_date() crashes when system time > year 2037

* Added a correct check for the timestamp range instead of just variable size check to
SET TIMESTAMP.
* Added overflow checking before converting to time_t. 
* Using a correct localized error message in this case instead of the generic error.
* Added a test suite.
* fixed the checks so that they check for unsigned time_t as well. Used the checks 
  consistently across the source code.
* fixed the original test case to expect the new error code.

Fix backported from to 5.0.
"Remove the alignment option, let valgrind use its default"

Updated the copyright.

Backport to 5.0.

/*![:version:] Query Code */, where [:version:] is a sequence of 5 
digits representing the mysql server version(e.g /*!50200 ... */),
is a special comment that the query in it can be executed on those 
servers whose versions are larger than the version appearing in the 
comment. It leads to a security issue when slave's version is larger 
than master's. A malicious user can improve his privileges on slaves. 
Because slave SQL thread is running with SUPER privileges, so it can
execute queries that he/she does not have privileges on master.
      
This bug is fixed with the logic below: 
- To replace '!' with ' ' in the magic comments which are not applied on
  master. So they become common comments and will not be applied on slave.
      
- Example:
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
   will be binlogged as
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/

- Removed files specific to compiling on OS/2
- Removed files specific to SCO Unix packaging
- Removed "libmysqld/copyright", text is included in documentation
- Removed LaTeX headers for NDB Doxygen documentation
- Removed obsolete NDB files
- Removed "mkisofs" binaries
- Removed the "cvs2cl.pl" script
- Changed a few GPL texts to use "program" instead of "library"

file .\item_subselect.cc, line 836
     
IN quantified predicates are never executed directly. They are rather wrapped
inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
execution. However, this is not done during query preparation. Unfortunately
the LIKE predicate pre-evaluates constant right-hand side arguments even
during name resolution. Likely this is meant as an optimization.
      
Fixed by not pre-evaluating LIKE arguments in view prepare mode.

Back-ported to 5.0s

The user-visible problem was that changes to column-level privileges,
happened in between of PREPARE and EXECUTE of a prepared statement, were
neglected. I.e. a prepared statement could be executed with the
column-level privileges as of PREPARE-time. The problem existed for
column-level privileges only.

A similar problem existed for stored programs: the changes between
executions didn't have an effect.

Technically the thing is that table references are cached in
Prepared_statement::prepare() call. In subsequent
Prepared_statement::execute() calls those cached values are used.
There are two functions to get a field by name: find_field_in_table() and
find_field_in_table_ref(). On prepare-phase find_field_in_table_ref() is
called, on execute-phase -- find_field_in_table() because the table is
cached. find_field_in_table() does not check column-level privileges and
expects the caller to do that. The problem was that this check was
forgotten.

The fix is to check them there as it happens in find_field_in_table_ref().

Original revid: alexey.kopytov@sun.com-20100723115254-jjwmhq97b9wl932l

 > Bug #54476: crash when group_concat and 'with rollup' in
 >                      prepared statements
 >
 > Using GROUP_CONCAT() together with the WITH ROLLUP modifier
 > could crash the server.
 >
 > The reason was a combination of several facts:
 >
 > 1. The Item_func_group_concat class stores pointers to ORDER
 > objects representing the columns in the ORDER BY clause of
 > GROUP_CONCAT().
 >
 > 2. find_order_in_list() called from
 > Item_func_group_concat::setup() modifies the ORDER objects so
 > that their 'item' member points to the arguments list
 > allocated in the Item_func_group_concat constructor.
 >
 > 3. In some cases (e.g. in JOIN::rollup_make_fields) a copy of
 > the original Item_func_group_concat object could be created by
 > using the Item_func_group_concat::Item_func_group_concat(THD
 > *thd, Item_func_group_concat *item) copy constructor. The
 > latter essentially creates a shallow copy of the source
 > object. Memory for the arguments array is allocated on
 > thd->mem_root, but the pointers for arguments and ORDER are
 > copied verbatim.
 >
 > What happens in the test case is that when executing the query
 > for the first time, after a copy of the original
 > Item_func_group_concat object has been created by
 > JOIN::rollup_make_fields(), find_order_in_list() is called for
 > this new object. It then resolves ORDER BY by modifying the
 > ORDER objects so that they point to elements of the arguments
 > array which is local to the cloned object. When thd->mem_root
 > is freed upon completing the execution, pointers in the ORDER
 > objects become invalid. Those ORDER objects, however, are also
 > shared with the original Item_func_group_concat object which is
 > preserved between executions of a prepared statement. So the
 > first call to find_order_in_list() for the original object on
 > the second execution tries to dereference an invalid pointer.
 >
 > The solution is to create copies of the ORDER objects when
 > copying Item_func_group_concat to not leave any stale pointers
 > in other instances with different lifecycles.