1. 14 Oct, 2006 4 commits
  2. 13 Oct, 2006 7 commits
  3. 12 Oct, 2006 11 commits
  4. 11 Oct, 2006 13 commits
  5. 09 Oct, 2006 2 commits
    • cmiller@zippy.cornsilk.net's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-4.1-maint · 0ab343a7
      cmiller@zippy.cornsilk.net authored
      into  zippy.cornsilk.net:/home/cmiller/work/mysql/bug17583/my41-bug17583
      0ab343a7
    • cmiller@zippy.cornsilk.net's avatar
      Bug#17583: mysql drops connection when stdout is not writable · 4812d81e
      cmiller@zippy.cornsilk.net authored
      When the client program had its stdout file descriptor closed by the calling
      shell, after some amount of work (enough to fill a socket buffer) the server 
      would complain about a packet error and then disconnect the client.
      
      This is a serious security problem.  If stdout is closed before the mysql is
      exec()d, then the first socket() call allocates file number 1 to communicate
      with the server.  Subsequent write()s to that file number (as when printing
      results that come back from the database) go back to the server instead in 
      the command channel.  So, one should be able to craft data which, upon being
      selected back from the server to the client, and injected into the command
      stream become valid MySQL protocol to do something nasty when sent /back/ to 
      the server.
      
      The solution is to close explicitly the file descriptor that we *printf() to, 
      so that the libc layer and the OS layer both agree that the file is closed.
      4812d81e
  6. 08 Oct, 2006 3 commits