Neden cron sessizce senaryomda sudo sayfalarını çalıştırmıyor?

Bazı komutları kullanan, ayrıcalıklı olmayan bir kullanıcının crontab'ından çalışan bir betiğim var sudo. Dışında değil. Betik iyi çalışıyor ancak sudo'ed komutları sessizce başarısız oluyor.

Betik, söz konusu kullanıcı olarak bir kabuktan kusursuz bir şekilde çalışır.
Sudo şifre gerektirmez. Söz konusu kullanıcının içinde (root) NOPASSWD: ALLerişim izni var /etc/sudoers.
Cron çalışıyor ve betiği çalıştırıyor. Basit bir ekleme date > /tmp/log, doğru zamanda çıktı üretir.
Bu bir izin sorunu değil. Yine komut dosyası sudo'ed komutlarını değil, idam edilir.
Bu bir yol problemi değil. Çalıştırılan envbetiğin içinden çalıştırmak, $PATHsudo yolunu içeren doğru değişkeni gösterir . Tam yol kullanarak çalıştırmak yardımcı olmuyor. Gerçekleştirilen komuta tam yol adı verilmiştir.
STDERR de dahil olmak üzere sudo komutunun çıktısını almaya çalışmak yararlı bir şey göstermiyor. sudo echo test 2>&1 > /tmp/logKomut dosyasına ekleme boş bir günlük oluşturur.
Sudo binaryinin kendisi gayet iyi yürütür ve betiğin içindeki crondan çalıştırıldığında bile izinlerinin olduğunu bilir. sudo -l > /tmp/logKomut dosyasına ekleme , çıktısını üretir:

Ec2 kullanıcısı bu ana bilgisayarda aşağıdaki komutları çalıştırabilir:
(root) NOPASSWD: ALL

Kullanarak komutun çıkış kodunu incelemek $?bir hata döndürdüğünü gösterir (çıkış kodu:) 1, ancak hiçbir hata oluşmuyor gibi görünüyor. Basit bir komut /usr/bin/sudo /bin/echo testaynı hata kodunu döndürür.

Başka neler olabilir?

Bu son Amazon Linux AMI çalıştıran yeni oluşturulan bir sanal makine. Crontab kullanıcıya aittir ec2-userve sudoers dosyası dağıtım varsayılanıdır.

sudo cron

— Caleb
kaynak

Bir çözüm hakkında konuşacaktım ama sonra okudum The user in question has (root) NOPASSWD: ALL access granted in /etc/sudoersve beynim okumaya devam etmek için çok yüksek sesle çığlık atmaya başladı.

— Shadur

@Shadur: Elinizle konuşun. Bu benim de makine kurma yöntemim değil, ancak bu makineler kutudan çıktı. Makine size ait olsa bile, bir root şifresi alamazsınız, kutunun sahibi olarak anahtarınız (belirtildiği gibi) tam sudo erişimi olan ec2 kullanıcı hesabına girer. Ec2 kullanıcısı için bir şifre almadıysanız, bir tane belirlemediğiniz sürece, bu sadece bir anahtar kelime girişidir.

— Caleb

O zaman tavsiye edebileceğim ilk şey sudo, betikte ihtiyacın olan komutlar için / sadece / sadece sınırlı haklara sahip ayrı bir kullanıcı kurmak ve giriş yeteneklerini tamamen devre dışı bırakmak.

— Shadur

Kökünüz varsa ve cron işinin root olarak çalışmasını istiyorsanız, neden ec2-kullanıcının crontab'ına koydunuz? root'un crontab'ı daha uygun olmaz mıydı? veya / etc / crontab?

— Cas

@CraigSanders: cron işinin root olarak çalışmasını istemiyorum, aslında çoğu kullanıcı olarak çalıştırılmalıdır. Soru, bir işi kök olarak çalıştırmak değil, sudo aracılığıyla bir işleve özel erişimi olan bir betikle ilgilidir.

— Caleb

Sudo'nun izin dosyasında, biri cronu olmayan bir TTY içinde çalışan mermilerde kullanımıyla ilgili bir kısıtlamaya izin veren bazı özel seçenekler vardır.

Amazon Linux AMI dahil bazı dağıtımlar bunu varsayılan olarak etkinleştirdi. /etc/sudoersDosya şu şekilde görünecektir:

# 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

STDERR'ye sudo komutunun kendisinden ziyade kabuk betiği düzeyinde çıktı yakalamış olsaydınız şöyle bir mesaj alırsınız:

üzgünüm, sudo çalıştırmak için bir tty'niz olmalı

Çözüm, sudo'nun TTY dışındaki ortamlarda bu seçenekleri kaldırarak veya yorum yaparak yürütmesine izin vermektir:

#Defaults    requiretty
#Defaults   !visiblepw

— Caleb
kaynak

CentOS'un bu kısıtlamaları yerine getirdiğini onaylayabilirim.

— aeu