rootパスワードなしでcronジョブでmysqldumpを使用する
ボックスにrootパスワードでログインした場合、次のように入力できます
mysqldump --all-databasesと期待される「ダンプ」を取得します。
Cron.dailyでジョブをセットアップして実行し、これをバックアップドライブにダンプします。私が抱えている問題は、ユーザーがルートとして実行されているにもかかわらず、次のメッセージが表示されることです
mysqldump：Got error：1045：Access denied for user 'root' @ 'localhost'（using password：NO）
接続しようとしたとき。私はしないでください mysqlデータベースのrootパスワードをスクリプトにハードコーディングしたいと思います（誰がそうするでしょう）。
Bashシェルのコマンドラインで「mysqldump」と入力するだけでよいことを考えると、-uパラメーターを使用して回避する方法がいくつかあるはずです。スクリプトの先頭に＃！/ bin/bashがすでにあります。
データベースにrootパスワードを要求しないようにするために、ここで何が欠けていますか？
Mysqlサーバーに接続するには、資格情報を提供する必要があります。それらを構成ファイルで指定するか、コマンドラインを介して渡すか、資格情報を必要としないアカウントを作成できます。
もちろん、no-passwordオプションは決して使用すべきではありません。psを実行できる人なら誰でもコマンドラインを見ることができる可能性があるため、pass-byコマンドラインは素晴らしいものではありません。
推奨オプションは、資格情報を含む mysql構成ファイル を作成し、ファイルシステムのアクセス許可でそのファイルを保護して、バックアップユーザーだけがアクセスできるようにすることです。
Rootとしてインタラクティブにログインしている間にmysqlサーバーにログインできるのは、rootパスワードが設定されていないか、スクリプトで見つからない構成ファイルがあることを示唆しているようです。 .my.cnfがある場合は、手動でポイントする必要があります。 rootアカウントにパスワードが設定されていない場合は、修正することを強くお勧めします。
更新（2016-06-29）mysql 5.6.6以降を実行している場合は、暗号化ファイルに 資格情報を保存 できる mysql_config_editor ツールを確認する必要があります。 Giovanni に感謝します。
セキュリティはあいまいさを介して行われるべきではありません。 mysqlダンプまたはデータベースファイルですべてのデータを利用できるため、誰かがrootアカウントへのアクセスを恐れている場合、rootのmysqlパスワードがスクリプトに格納されているかどうかは問題ではありません。それで、本当の問題はあなたが何を保護しようとしているのですか？
他のユーザーがデータベースのデータを変更できるパスワードを取得したくない場合は、 適切な権限 のユーザーを作成する必要があります。
そのmysqlパスワードをroot以外のローカルアカウントに見られたくない場合は、スクリプトの file permissions を0700に設定し、所有者をrootに設定します。
シェルを使用してシェルを実行できるため、シェルを使用できます。つまり、ログオンすると、プロファイル内のすべてのシェルスクリプトが実行されます。
Cronにはそのような贅沢はありません。 （rootとして）ログオンすると、デフォルトのシェルでログオンします。これにより、誰もリモートでログオンできなくなりますが、実行される自動ログインスクリプトがないことも意味します。
Cronを実行するシェルを設定し、crontabを編集して、シェル変数とHOME変数を追加できます。
Shell=/bin/bash
HOME=/root
これらが設定されていない場合、cronはシェルと/ etc/passwdで指定されたホームディレクトリ（おそらく何もない、おそらく/ bin/sh）で実行されます。
Cronが実行されている環境を確認するには、次のように、envをファイルにエクスポートするcronジョブを追加します。
$crontab -e
* * * * * env > /tmp/crontabenv.log
:wq
スクリプトがrootによって実行される場合、ファイル/ root/.my.cnfをパーミッション600と次の内容で作成できます。
[client]
user = DBUSERNAME
password = DBPASSWORD
（もちろん、MySQLのユーザー名とパスワードを入力します）。
このファイルがルートとして実行されている場合、mysqlコマンドラインツールによって自動的に読み取られます。コマンドラインでそれを提供する必要はもうありません。 600のアクセス許可は、それを覗き見から保護します。
Cronはデバッグが非常にイライラすることがあります。 cronジョブが実行されるとき、シェルで当たり前のように設定された環境はありません。
Cronのヒント：
- 「ECHO =/bin/echo」など、すべてへのフルパスを使用します（簡単にするために、上部に変数を定義します）
- mAILTOを設定して、各ジョブからメールを受け取る（またはジョブにstderr/stdoutをファイルにリダイレクトさせる）
Rootユーザーがシェルから実行できる場合、cronがそれを実行できるはずです。コマンドラインで使用する構成ファイルを明示的に指定していることを確認してください。
これらの応答のいくつかは役に立ちますが、UNIXのrootユーザーとmysqlのrootユーザーは同じではなく、どちらもログイン名「root」を使用する以外は基本的に関係がないため、いくつかは混乱しています。多分それは明白ですが、いくつかの応答は2つを混乱させるようです。
Mysqldの便利なオプション（存在する可能性がありますか？） my.cnfファイルまたは同様のもの。
私はそれが多少神経質になることを知っていますが、推論はローカルとして（mysqldサーバーに対して）実行している誰でもunix rootがmysqldのセキュリティを非常に簡単にバイパスできることです。そしてmysqldルートパスワードを7x24でmy.cnfに設定するか、またはmysqlルートパスワードを使用してmy.cnfを作成/削除すると（そのパスワードはどこから取得されますか？）オンザフライで（たとえば、mysqldumpを実行するため）私緊張しています。
ローカルのUNIXルートアカウントによって実行されていると本当に信じていることをmysqldに送信するにはmysql/mysqldump/etcを信頼する必要があるため、インフラストラクチャと思考が必要になります。
しかし、たとえば、少なくともこのオプションの強く推奨されるオプションとして、mysqldのUNIXソケットのみに制限し、TCPは制限しないと役立つ場合があります。これにより、クライアントがローカルで実行されていることが確認できますが、それだけでは不十分です。しかし、それはアイデアの始まりかもしれません。おそらく、Unixソケットを介してファイル記述子を送信することは、別の部分になる可能性があります（それが狂ったように聞こえる場合は、Googleでそれをググってください）。
追伸いいえ、ここでブレインストーミングを行って、UNIX以外のオペレーティングシステムでどのように機能するかを考えて、そのアイデアがおそらく他のOSに変換されるとは思いません。