Sử dụng mysqldump trong cron job mà không cần mật khẩu root

14

Nếu tôi đăng nhập bằng mật khẩu gốc trên hộp của mình, tôi chỉ cần gõ

mysqldump - tất cả các cơ sở dữ liệu và tôi sẽ nhận được "Dump" dự kiến.

Tôi thiết lập một công việc trong cron.d Daily để chạy và kết xuất công việc này vào ổ đĩa sao lưu. Vấn đề tôi gặp phải là mặc dù người dùng đang chạy bằng root nhưng tôi nhận được thông báo sau

mysqldump: Có lỗi: 1045: Truy cập bị từ chối đối với người dùng 'root' @ 'localhost' (sử dụng mật khẩu: NO)

khi cố gắng kết nối. Tôi không muốn mã cứng mật khẩu gốc cơ sở dữ liệu mysql trong tập lệnh (ai sẽ).

Xem xét rằng tôi chỉ có thể gõ "mysqldump" vào dòng lệnh trong bash shell của mình, phải có cách nào đó để sử dụng tham số -u. Tôi đã có #! / Bin / bash ở đầu tập lệnh.

Tôi còn thiếu gì ở đây để có được điều này để không yêu cầu mật khẩu root vào cơ sở dữ liệu?

mysql scripting cron

— Phần mềm cơ điện tử
nguồn

12

Để kết nối với máy chủ mysql, bạn phải cung cấp thông tin đăng nhập. Bạn có thể chỉ định chúng trong tệp cấu hình, chuyển chúng qua dòng lệnh hoặc chỉ cần tạo tài khoản không yêu cầu thông tin đăng nhập.

Tất nhiên không bao giờ nên sử dụng tùy chọn không có mật khẩu, dòng lệnh truyền qua không tuyệt vời vì bất kỳ ai có thể chạy ps đều có thể thấy dòng lệnh.

Tùy chọn được đề xuất là tạo tệp cấu hình mysql với thông tin đăng nhập trong đó và sau đó bảo vệ tệp đó bằng quyền hệ thống tệp để chỉ người dùng sao lưu của bạn có thể truy cập tệp.

Bạn có thể đăng nhập vào máy chủ mysql khi đăng nhập tương tác vì root dường như gợi ý rằng bạn không có mật khẩu gốc hoặc bạn có tập tin cấu hình không được tìm thấy bởi tập lệnh của bạn. Nếu bạn có một .my.cnf, bạn có thể cần phải tự trỏ đến nó. Nếu tài khoản root của bạn không có mật khẩu được đặt thì tôi rất khuyến khích bạn khắc phục điều đó.

Cập nhật (2016-06-29) Nếu bạn đang chạy mysql 5.6.6 trở lên, bạn nên xem công cụ mysql_config_editor cho phép bạn lưu thông tin đăng nhập trong một tệp được mã hóa. Cảm ơn Giovanni đã đề cập điều này với tôi.

— Zoredache
nguồn

1

Phương pháp đó vẫn yêu cầu mật khẩu không được mã hóa bằng văn bản thuần túy trên hệ thống. Đó là những gì tôi đang cố gắng tránh.

— Phần mềm Mech

> bạn không có bộ mật khẩu gốc hoặc tập tin cấu hình không được tìm thấy bởi tập lệnh của bạn. Tác giả nói rõ rằng có mật khẩu mysql cho root và anh ta đang cố truy cập cơ sở dữ liệu mà không cung cấp cho lệnh mysqldump: "(sử dụng mật khẩu: NO)". Do đó truy cập bị từ chối lỗi.

— monomyth

1

@monomyth, tác giả cũng nói rằng anh ta có thể đăng nhập mà không cần mật khẩu trong khi đăng nhập tương tác với quyền root. Điều này cho tôi biết một cái gì đó không đúng.

— Zoredache

2

Phần mềm @Mech, không có nhiều điểm cố gắng để bảo vệ bạn khỏi tài khoản root. Nếu ai đó có tài khoản root, họ có thể chỉ cần khởi động lại mysql và bỏ qua hoàn toàn hệ thống cấp phép.

— Zoredache

1

Lý do tôi có thể đăng nhập là tài khoản root có .my.cnf được chỉ định với 600 quyền, do đó, đó là cách shell được truy cập. Tuy nhiên, cron phải bỏ qua tập tin vì vậy tôi đã sử dụng tham số trong bài viết này để trỏ đến nó.

— Phần mềm Mech

3

Bảo mật không nên được thực hiện thông qua tối nghĩa. Nếu bạn sợ rằng ai đó có quyền truy cập vào tài khoản root của bạn, thì việc mật khẩu mysql của root được lưu trong tập lệnh không thành vấn đề, vì bạn có tất cả dữ liệu của mình trong các tệp mysql hoặc tệp cơ sở dữ liệu. Vì vậy, câu hỏi thực sự là bạn đang cố gắng bảo vệ cái gì?

Nếu bạn không muốn người khác lấy mật khẩu cho phép họ thay đổi dữ liệu trong cơ sở dữ liệu của bạn, bạn sẽ cần tạo một người dùng có quyền thích hợp .

Nếu bạn không muốn mật khẩu mysql được nhìn thấy bởi bất kỳ tài khoản cục bộ nào ngoại trừ quyền truy cập tập tin gốc trên tập lệnh đó là 0700 và chủ sở hữu để root.

— đơn điệu
nguồn

1

Tôi đoán điều tôi vẫn không hiểu là nếu tôi có thể gõ (từ dấu nhắc gốc) mysqldump không có mật khẩu nhập, tại sao tôi không thể chạy nó thông qua công việc định kỳ theo cùng một cách. Phần nào bị thiếu yêu cầu tham số -p. Tôi không cố gắng "che khuất" mật khẩu, tôi chỉ muốn không bao giờ nhập nó. Một cái gì đó đặc biệt cho chính đăng nhập gốc đang cho phép truy cập, vậy tại sao điều này không thể được sao chép bằng cron?

— Phần mềm Mech

Nếu bạn thấy rằng bạn có thể đăng nhập mà không cần mật khẩu và với mật khẩu sử dụng cùng một người dùng "root", có thể có nhiều người dùng root trong cơ sở dữ liệu mysql của bạn. Một số trong số họ có thể không có mật khẩu được thiết lập. Bạn có thể xóa mật khẩu khỏi 'root' @ 'localhost' nhưng sau đó, không chỉ cron mới có thể kết nối với cơ sở dữ liệu của bạn, mà bất kỳ ai có tài khoản cục bộ. Điều này không khác (hoặc tệ hơn) so với việc có mật khẩu trong một tập lệnh văn bản rõ ràng.

— monomyth

Tôi nghĩ vấn đề là MechSoftware đã tạo ra rằng về cơ bản là root cho phép bạn đọc quyền truy cập vào các tệp cơ sở dữ liệu và chúng không được mã hóa. Do đó, yêu cầu mật khẩu MySQL gốc từ người dùng root chỉ để in đẹp dữ liệu mà về cơ bản họ đã có thể truy cập là "bảo mật thông qua che khuất". Bên cạnh đó, các quyền rất dễ gây rối, ví dụ: nếu ai đó đang đặt chúng theo cách đệ quy cho một thư mục, nếu có một liên kết tượng trưng đến tệp, v.v.

— Septagram

2

Việc sử dụng shell của bạn có thể thực hiện được vì bạn có shell để chạy nó, tức là khi bạn đăng nhập, tất cả các tập lệnh shell trong hồ sơ của bạn sẽ chạy.

Cron không có những thứ xa xỉ như vậy. Khi nó đăng nhập (với quyền root), nó sẽ đăng nhập với shell mặc định. Điều này ngăn bất kỳ ai đăng nhập từ xa, nhưng điều đó cũng có nghĩa là không có tập lệnh đăng nhập tự động nào được chạy.

Bạn có thể đặt shell cho cron chạy bên dưới, chỉnh sửa crontab và thêm các biến SHELL và HOME, vd.

SHELL=/bin/bash
HOME=/root

nếu chúng không được đặt, thì cron sẽ chạy với thư mục shell và home được chỉ định trong / etc / passwd (có lẽ không có gì, có thể là / bin / sh).

Nếu bạn muốn xem cron môi trường đang chạy, hãy thêm một công việc cron xuất env vào một tệp, ví dụ:

$crontab -e
* * * * * env > /tmp/crontabenv.log
:wq

— gbjbaanb
nguồn

1

Nếu tập lệnh được chạy bởi root, bạn có thể tạo tệp /root/.my.cnf với quyền 600 và các nội dung sau:

[client]
user = DBUSERNAME
password = DBPASSWORD

(nơi bạn nhập tên người dùng và mật khẩu MySQL của bạn).

Tập tin này sẽ tự động được đọc bởi bất kỳ công cụ dòng lệnh mysql nào, nếu nó được chạy dưới quyền root. Không cần phải cung cấp nó trên dòng lệnh. 600 quyền bảo vệ nó chống lại con mắt tò mò.

— Heemels Martijn
nguồn

1

Tôi thấy đây là trường hợp CÁCH tôi có thể sử dụng mysqldump mà không cần mật khẩu. Vì vậy, điều này đã giải quyết bí ẩn về cách SHELL đang làm điều đó, vậy tại sao cron không đọc nó?

— Phần mềm Mech

1

mysqldump khi chạy từ cron có thể không xác định được tệp .my.cnf. Biện pháp khắc phục là thêm một tham số mysqldump để đọc rõ ràng các tùy chọn trong tệp.my.cnf, tức là --defaults-Extra-file = / root / .my.cnf Tôi đã học được điều này từ hai câu trả lời khác trên Stack Overflow. Xem stackoverflow.com/a/602054/854680 và stackoverflow.com/a/890554/854680

— MikeOnline

1

Cron có thể rất bực bội để gỡ lỗi. Khi các công việc định kỳ thực thi, chúng không có một môi trường như bạn được cấp với một vỏ.

Lời khuyên cho cron:

sử dụng đường dẫn đầy đủ đến mọi thứ - "ECHO = / bin / echo", v.v: (xác định các biến ở trên cùng để dễ dàng hơn)
đặt MAILTO, để bạn nhận được email từ mỗi công việc (hoặc yêu cầu chuyển hướng stderr / stdout thành tệp)

Nếu người dùng root của bạn có thể làm điều đó từ shell, cron sẽ có thể làm điều đó. Hãy chắc chắn rằng bạn chỉ định rõ ràng tệp cấu hình sẽ sử dụng trên dòng lệnh.

0

Mặc dù một vài trong số những phản hồi này rất hữu ích nhưng một số người lại nhầm lẫn vì người dùng root unix và người dùng root mysql không giống nhau và về cơ bản không có mối quan hệ nào ngoài việc cả hai đều sử dụng tên đăng nhập 'root'. Có thể đó là điều hiển nhiên nhưng có vẻ như một số câu trả lời đã khiến cả hai phải bối rối.

Điều gì có thể là một tùy chọn hữu ích (có thể tồn tại?) Đối với mysqld sẽ là cho phép các chương trình máy khách như mysql hoặc mysqldump, v.v. chạy dưới dạng unix root để truy cập root @ localhost của mysqld mà không cần mật khẩu mà không phải lưu trữ mật khẩu root @ localhost (mysql) trong một tập tin my.cnf hoặc tương tự.

Tôi biết điều đó làm cho một số lo lắng nhưng lý do là bất cứ ai đang chạy như cục bộ (đến máy chủ mysqld) unix root có thể vượt qua bảo mật của mysqld dù sao, khá dễ dàng. Và việc có một my.cnf với mật khẩu gốc mysqld 7x24 hoặc thậm chí tạo / xóa một my.cnf bằng mật khẩu gốc mysql (mật khẩu đó đến từ đâu?) Khi đang di chuyển (ví dụ, để thực hiện mysqldump) khiến tôi lo lắng.

Nó sẽ đòi hỏi một số cơ sở hạ tầng và suy nghĩ bởi vì người ta sẽ phải tin tưởng vào mysql / mysqldump / etc để truyền tới mysqld rằng nó thực sự tin rằng nó đang được điều hành bởi một tài khoản gốc unix cục bộ.

Nhưng ví dụ, chỉ giới hạn ở ổ cắm unix của mysqld, không có TCP, có thể giúp đỡ, ít nhất là một tùy chọn được khuyến nghị mạnh mẽ của tùy chọn này. Điều đó có thể chứng minh rằng máy khách đang chạy cục bộ tho có lẽ không đủ. Nhưng nó có thể là một khởi đầu của một ý tưởng. Có lẽ việc gửi một mô tả tập tin qua một ổ cắm unix có thể là một phần khác (google nó nếu điều đó nghe có vẻ như nói chuyện điên rồ.)

Tái bút: Tôi sẽ không cố gắng động não ngay tại đây làm thế nào bất kỳ thứ nào trong số đó có thể hoạt động trên một hệ điều hành không trộn lẫn, ý tưởng có thể chuyển sang các hệ điều hành khác.

— Barry Shein
nguồn

1

Đưa thông tin đăng nhập /root/.my.cnfvới quyền thích hợp giải quyết gọn gàng vấn đề.

— Michael Hampton

Tôi không đồng ý, bây giờ bất cứ ai có thể truy cập vào tệp đó, bao gồm cả thông qua một số lỗ hổng hệ thống khác, đều có gốc mys mys pw. Và nó có 24x7 để bị tấn công và ở một vị trí tệp cố định (tho phải thừa nhận rằng nó sẽ không phải ở / root.) Nhưng ví dụ, bất cứ ai chạy các hệ thống tệp, hoặc có thể truy cập vào một tệp, có thể kéo nó ra khỏi một tập tin hệ thống kết xuất tập tin. Trong trường hợp đó có vẻ như một sự cám dỗ cho một nhân viên bất mãn. Tôi nghĩ rằng đó là một mục tiêu hợp lý rằng không có mật khẩu Cleartext tồn tại trên một hệ thống, ở bất cứ đâu.

— Barry Shein

Có thể là như vậy, nhưng đề xuất bạn đưa ra còn tệ hơn nhiều, vì nó cho phép bất kỳ người dùng địa phương nào giả vờ tầm thường là root.

— Michael Hampton

Không, đề xuất của tôi là họ đã phải hủy root trên máy chủ cục bộ, trong trường hợp mysqld cục bộ tin tưởng mys mys hoặc mysqldump, v.v. (client) đang chạy dưới dạng root unix và cho phép họ tiến hành như thể họ đã xác thực là root mysql . Như tôi đã nói nếu họ đã unix root cục bộ với máy chủ, họ có thể vượt qua mật khẩu gốc mysql bằng một vài lệnh được ghi chép tốt ("phục hồi mật khẩu gốc mysql").

— Barry Shein