8

INTOOUTFILEコマンドを使用しているときに問題が発生し続ける理由を理解しようとしています。

私はいつもこのエラーが発生します：

ERROR 1 (HY000): Can't create/write to file '/var/www/p1.txt' (Errcode: 13)


SELECT password FROM mysql.user WHERE user='root' INTO OUTFILE '/var/www/p1.txt';

役立つ詳細：

  • Webアプリケーション：DVWA（localhost）（調査目的）

  • サーバー：Apache / 2.2.14（Ubuntu）-PHP / 5.3.2

  • MySQLバージョン5.1.63

  • オペレーティングシステムLinuxBacktrack5r3。

rootとしてコマンドを実行しています。また、/ var /www/にフォルダやファイルを自由に作成できます

Errcode 13許可が拒否されたことを意味しますが、問題を解決するにはどうすればよいですか？

どんな助けでも大歓迎です。

4

7 に答える 7

11

rootとしてMySQLにログインしている場合でも、ファイルの書き込みは実際のMySQLデーモンを実行しているユーザーとして実行されます。

つまり、どのユーザーがmysqldを実行しているかを確認し、そのユーザーのディレクトリへの書き込み権限を付与する必要があります。

于 2013-01-19T16:37:26.473 に答える
6

ユーザーの権限を変更する必要がありますmysqld。次のコマンドsudo aa-statusを実行して、ユーザーステータスと許可されたディレクトリを確認することから始めます。権限を変更する場合は、必要な/etc/apparmor.d/usr.sbin.mysqldディレクトリを編集して挿入します。

その後、apparmorを再起動する必要がありますsudo /etc/init.d/apparmor restart

于 2013-11-30T16:54:27.157 に答える
3

ファイルを書き込もうとしているユーザーに/var/ wwwをchownするか、chmod 777 / var / www

これはおそらく安全な方法ではありません。ファイルを別の場所に置くことを検討することをお勧めします

于 2013-01-19T16:38:17.880 に答える
2

この投稿はかなり古いものですが、2018年もこの問題はまだ残っています。私はこの迷路の中で頭を叩いて数時間過ごしました。

サーバーバージョン：Ubuntu14.04で実行されている5.7.24MySQL Community Server（GPL）

  1. MySqlがSELECTINTOOUTFILEを使用できるようにするには、構成でMySQLのsecure-file-privオプションを設定する必要があります。次の2行を次のように追加します/etc/mysql/mysql.conf。

    [mysqld]
# allow INTO OUTFILE file and LOAD DATA INFILE to this directory
secure_file_priv=/usr/share/mysql-files

  2. /usr/share/mysql-filesファイルが保存されるディレクトリです。私はそれを次のように作成しました：

    sudo su
cd /usr/share
mkdir mysql-files
chown mysql:mysql mysql-files
chmod a+rw mysql-files

好きなように変更しますが、ディレクトリ /usr/share/mysql-filesの使用は避けてください。/tmp

なんで？ なぜなら、次回再起動するときに/tmp、貴重なmysql-filesサブディレクトリを含むディレクトリが正常に消去されるからです。その後、mysqlサービスがチョークし、起動せず、暗号化メッセージで奇妙なエラーが発生します。

  1. mysqlを再起動し、以下を確認します。

    sudo su
service mysql restart
mysql
mysql> SHOW VARIABLES LIKE "%secure%";
+--------------------------+-------------------------+
| Variable_name            | Value                   |
+--------------------------+-------------------------+
| require_secure_transport | OFF                     |
| secure_auth              | ON                      |
| secure_file_priv         | /usr/share/mysql-files/ |
+--------------------------+-------------------------+
3 rows in set (0.07 sec)
mysql> quit
Bye

  2. まだ終わっていません！

apparmorあなたのプロジェクトを台無しにする人の名前による荒らしがあります。ファイルを編集し/etc/apparmor/local/usr/sbin/mysqld、次の2行を追加します-終了コンマを忘れないでください：

    /usr/share/mysql-files rw,
    /usr/share/mysql-files/** rw,

保存して再解析します。

sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld

それでうまくいくはずです。

于 2018-12-13T11:21:43.737 に答える
0

CentOSでは、selinuxがうまく機能していません。

$ getenforce
Enforcing

$ setenforce 0
Permissive

これは大雑把ですが、私にとってはうまくいきました（再起動するまで、その後スイッチがオンに戻ります）。この一時的な対策が機能する場合は、selinuxを適切に構成する方法をグーグルで検索する必要があります。

于 2015-01-28T22:06:06.653 に答える
0

mysqldのユーザーを次のように確認します。

ps -aef | grep mysql
mysql     9355  9102  0 Aug24 ?        21:53:25 /usr/libexec/mysqld

mysqlが属するwiichグループを確認します。

groups mysql
mysql : mysql www

次に、mysqlに属するパス、またはグループwwwとmysqlの書き込み権限を持つファイルを書き込みます。たとえば、下のテストには、グループwwwへの書き込み権限があります。

ll /data/
drwxrwxr-x 2 www    www 4096 Dec  9 19:31 test

次に、mysqlを実行しますmysql -u root -p -e 'use sc_test; select file_path from sc_files INTO OUTFILE "/data/test/paths.txt";'

于 2019-12-09T11:36:56.473 に答える
0

私もこの謎めいたエラーと何時間も戦っていましたが、見つけたものはすべて試しましたが、役に立たなかったのですが、何年も前に同じ問題が発生していて、どれだけ検索しても解決策が見つからなかったことを思い出しました。これらすべての賢いカウンセルを試しました。

secure_file_priv私にとっては初めてのことでしたが、これを機能させるためだけにDockerコンテナーを再構築したくなかったため、これを試しませんでした。

解決

私のファイルを見ると、docker-composeこの問題の解決策が見つかりました。ターゲットディレクトリへのマッピングがなかったため、mysqlコンテナの場合、このディレクトリは存在しませんでした。

回避策

当時、私は自分のcron仕事の回避策を開発しました。

  1. tmpへの最初のダンプ（私のコンテナにはマッピングがあります）
  2. そもそもあるべき場所へのmv

まあ、それはうまくいくので、なぜわざわざ。

于 2021-01-14T22:42:58.717 に答える