Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[Jason Sipula]

You learn something new every day!

After your explanations, this situation makes perfect sense to me now. I
was attempting to quickly clone a database to basically rename it since
mysql removed the rename command a while ago (it was dangerous apparently).

It's pretty awesome that you guys took the time to explain this to me
instead of just blowing me off. Thank you very much.

-Jason


On Thu, Jul 11, 2013 at 11:04 AM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> On Thu, Jul 11, 2013 at 10:47:12AM -0700, Jason Sipula wrote:
> > I still think this is a bash issue. After the command terminates, you
> must
> > restart your bash session to return to normal functionality. Nothing
> typed
> > into the terminal displays but it does receive it.
>
> If the terminal has been messed up (which happens frequently when programs
> exit abnormally), then you'll need to run "reset" or some other command
> to reset the terminal.
>
> > Perhaps I'm
> > misunderstanding what bash's job is... I was under the impression the
> shell
> > was responsible for displaying text in the terminal.
>
> That's incorrect.  The terminal itself is responsible for displaying text
> in the terminal.  Bash simply reads commands from a file descriptor and
> runs them.  When the commands are running, they interact directly with
> the terminal, while bash goes to sleep.
>
>
> On Thu, Jul 11, 2013 at 07:47:47PM +0200, John Kearney wrote:
> >
> >    This isn't a but in bash.
> >    firstly once a program is started it takes over the input so the fact
> >    that your password is echoed to the terminal is because myspl allows
> it
> >    not bash, and in mysql defense this is the normal behaviour for
> command
> >    line tools.
>
> Well.  The issue is really that he's trying to run two separate instances
> of "mysql -p" in the same terminal at the same time.  They're competing
> for the same input stream, and that never works well.
>
> There is no "normal behavior" among programs that accept a password for
> authentication.  Some of them open /dev/tty directly.  Some of them
> read from standard input.  Some of them accept a password in a command
> line argument, or in an environment variable -- both of which are bad.
>
> >    Secondly both mysqldump  and mysql start at the same time and can
> >    potentially be reading the password also at the same time.
>
> (You described multiple stdin readers here.  I won't repeat that part.)
>
> >    basically you should give the password on the command line to mysql.
> >    something like
> >    read -sp "Password:" Password
> >    mysqldump -u someuser --password ${Password} -p somedb | mysql -u
> >    someuser --password ${Password} -p -D someotherdb
>
> First: use more quotes.  "$Password", not ${Password} or $Password.
>
> Second: passing the password (which is presumably supposd to remain
> secret) on the command line allows it to be visible to every user on
> the system.  On 99% of Unix systems in the world, anyway.  There are
> undoubtedly some small number where user can't run "ps -ef", or where
> they get limited output from it, but you shouldn't assume.
>
> There may be some setups where this solution is adequate, once it's
> been quoted correctly.  In most setups, it is unsafe.  It's up to Jason
> to decide whether his setup can permit this.
>
> I'd ask a mysql list for advice with this.  It's not something that can
> be generalized across applications.
>