Tại sao cron âm thầm không chạy sudo Stuff trong tập lệnh của tôi?

Tôi có một tập lệnh chạy từ crontab của người dùng không có đặc quyền gọi một số lệnh bằng cách sử dụng sudo. Ngoại trừ nó không. Kịch bản chạy tốt nhưng các lệnh sudo'ed âm thầm thất bại.

Kịch bản chạy hoàn hảo từ một trình bao như người dùng trong câu hỏi.
Sudo không yêu cầu mật khẩu. Người dùng trong câu hỏi có (root) NOPASSWD: ALLquyền truy cập được cấp trong /etc/sudoers.
Cron đang chạy và thực thi kịch bản. Thêm một date > /tmp/logđầu ra sản xuất đơn giản vào đúng thời điểm.
Đây không phải là vấn đề về quyền. Một lần nữa, tập lệnh được thực thi, không phải là các lệnh sudo'ed.
Đó không phải là một vấn đề con đường. Chạy envtừ bên trong tập lệnh đang chạy sẽ hiển thị $PATHbiến chính xác bao gồm đường dẫn đến sudo. Chạy nó bằng một đường dẫn đầy đủ không có ích. Lệnh đang được thực thi đang được cung cấp tên đường dẫn đầy đủ.
Cố gắng nắm bắt đầu ra của lệnh sudo bao gồm STDERR không hiển thị bất cứ điều gì hữu ích. Thêm sudo echo test 2>&1 > /tmp/logvào kịch bản tạo ra một bản ghi trống.
Bản thân nhị phân sudo thực thi tốt và nhận ra rằng nó có quyền ngay cả khi chạy từ cron bên trong tập lệnh. Thêm sudo -l > /tmp/logvào tập lệnh tạo đầu ra:

Người dùng ec2-user có thể chạy các lệnh sau trên máy chủ này:
(root) NOPASSWD: ALL

Kiểm tra mã thoát của lệnh bằng cách sử dụng $?cho thấy nó đang trả về lỗi (mã thoát 1:), nhưng dường như không có lỗi nào được tạo ra. Một lệnh đơn giản như /usr/bin/sudo /bin/echo testtrả về cùng một mã lỗi.

Điều gì khác có thể xảy ra?

Đây là một máy ảo được tạo gần đây chạy Amazon Linux AMI mới nhất. Crontab thuộc về người dùng ec2-uservà tệp sudoers là mặc định phân phối.

sudo cron

— Caleb
nguồn

Tôi định nói về một giải pháp nhưng sau đó tôi đọc The user in question has (root) NOPASSWD: ALL access granted in /etc/sudoersvà não tôi bắt đầu la hét quá lớn để tiếp tục đọc.

— Shadur

@Shadur: Nói chuyện với tay. Đó cũng không phải là cách thiết lập máy của tôi, nhưng những máy này ra khỏi hộp. Ngay cả thông qua máy là của bạn, bạn không nhận được mật khẩu gốc, khóa của bạn là chủ sở hữu của hộp đi vào tài khoản người dùng ec2 có quyền truy cập sudo đầy đủ (như đã lưu ý). Bạn không nhận được mật khẩu cho người dùng ec2 trừ khi bạn đặt mật khẩu, đó chỉ là khóa đăng nhập.

— Caleb

Sau đó, điều đầu tiên tôi khuyên bạn nên làm là thiết lập một người dùng riêng biệt với sudocác quyền bị hạn chế / chỉ / cho các lệnh bạn cần trong tập lệnh và vô hiệu hóa hoàn toàn khả năng đăng nhập của họ.

— Shadur

nếu bạn có root và bạn muốn công việc cron chạy bằng root, vậy tại sao lại đặt nó vào crontab của người dùng ec2? crontab của root sẽ không thích hợp hơn? hoặc / etc / crontab?

— cas

@CraigSanders: Tôi không muốn công việc định kỳ chạy bằng root, thực tế phần lớn nên được chạy như một người dùng. Câu hỏi không phải là về việc chạy một công việc như root, mà là về một tập lệnh có quyền truy cập đặc biệt vào một chức năng thông qua sudo.

— Caleb

Sudo có một số tùy chọn đặc biệt trong tệp quyền của nó, một trong số đó cho phép hạn chế sử dụng đối với các shell đang chạy bên trong TTY, mà cron thì không.

Một số bản phát hành bao gồm Amazon Linux AMI được bật theo mặc định. Các /etc/sudoerstập tin sẽ trông giống như thế này:

# Disable "ssh hostname sudo <cmd>", because it will show the password in clear.
#         You have to run "ssh -t hostname sudo <cmd>".
#
Defaults    requiretty

#
# Refuse to run if unable to disable echo on the tty. This setting should also be
# changed in order to be able to use sudo without a tty. See requiretty above.
#
Defaults   !visiblepw

Nếu bạn đã bắt đầu ra tới STDERR ở cấp độ của tập lệnh shell chứ không phải chính lệnh sudo, bạn sẽ có vẻ như có một thông báo như thế này:

xin lỗi, bạn phải có một tty để chạy sudo

Giải pháp là cho phép sudo thực thi trong các môi trường không phải TTY bằng cách xóa hoặc nhận xét các tùy chọn sau:

#Defaults    requiretty
#Defaults   !visiblepw

— Caleb
nguồn

Tôi có thể xác nhận rằng CentOS có những hạn chế này.

— aeu