Eğer bir Bash betiği dosyası yürütürsem, Bash betiğinin içindeki tüm komutlar da sudo olarak mı çalıştırılır?


30

Bash'de otomatik bir yükleme sonrası betiği yazmak istiyorum ( post-install.shörneğin, denir ). Betik otomatik olarak depoları ekler ve günceller, paketleri kurar ve günceller, config dosyalarını düzenler vb.

Şimdi, eğer bu betiği çalıştırırsam, örneğin sudo post-install.sh, sadece bir sudokez şifre girmem istenecek mi , yoksa sudobetiğin içindeki her komut için sudoizin gerektiren bir şifre girmem mi gerekecek ? Başka bir deyişle, bash betiğinin içindeki komutlar yürütme izinlerini 'miras alıyor', öyle mi demek istiyorsun?

Ve eğer gerçekten yaparlarsa , sudoizinlerin zaman aşımına uğraması ihtimali var mı (örneğin, belirli bir komutun sudozaman aşımını aşması için yeterince uzun sürmesi halinde )? Yoksa ilk sudoşifre girişi tüm komut dosyasının tamamı boyunca devam edecek mi?


4
Bu görev için özel olarak tasarlanmış bazı araçları incelemek ilginizi çekebilir. 3 yaygın olanlar şunlardır: Kukla, şef ve soylu.
spuder

@spuder ve daha büyük ölçekli, kurumsal düzeyde mimari ve yapılandırma yönetimi güvenliği için, siz (kalbin zayıf için, ne için komutları tek seferlik.) CFEngine 3. kullanabilirsiniz
Wildcard

Yanıtlar:


38

S # 1: Sadece bir kez sudo şifresi girmem istenecek mi, yoksa sudo iznini gerektiren bir komutun her çağrısında sudo şifresini girmem gerekecek mi?

Evet, bir kez, betiğinizin çalışması süresince.

NOT: Kimlik bilgileri sağladığınızda sudo, kimlik doğrulama, şifreyi girdiğiniz kabukta 5 dakika boyunca iyidir. Ek olarak, bu kabuktan yürütülen tüm alt işlemler veya kabukta çalışan herhangi bir komut dosyası (davanızda) yüksek düzeyde çalışacaktır.

S # 2: sudo izinlerinin zaman aşımına uğraması ihtimali var mı (örneğin, belirli bir komut sudo zaman aşımını aşacak kadar uzun sürerse)? Yoksa ilk sudo şifresi girişi bütün betiğin tamamı boyunca devam edecek mi?

Hayır, komut dosyasında zaman aşımına uğramazlar. Yalnızca etkileşimli olarak, kimlik bilgilerinin sağlandığı kabuk içine yazıyorsanız. sudoBu kabukta her zaman yürütülür, zaman aşımı sıfırlanır. Ancak sizin durumunuzda, senaryo, içinde komutları çalıştırdığı ve çalıştırdığı sürece, bilgiler kalır.

sudo man sayfasından alıntı

Bu sınır poliçeye özgüdür; sudoers güvenlik politikası için varsayılan şifre istemi zaman aşımı süresi 5 dakikadır.


1
S1'in cevabı "Hayır, bir daha istenmeyecek."
dannysauer

@ dannysauer - tekrar Q'unu okudum. Sadece bir kez şifre sorulmasını Evet diyorum!
slm

Soru "a veya b" diyor ve sadece "evet" demek "evet, bir" veya "evet, b" olup olmadığını netleştirmedi. Sadece gelecek okuyucular için işleri netleştirmeye çalışıyorum. : D
dannysauer

@ dannysauer - güncellemeye bakınız.
slm

1
Bu yeni soru şuydu: stackoverflow.com/questions/3522341/… . sudo -u $(logname) <command>çalışmalı.
Gauthier

17

bashve tüm alt süreçleri süper kullanıcı izinleriyle çalışacak. Böylece bash betiğinizdeki komutlar için bir şifre girmenize gerek kalmayacak.

Zaman sudoaşımı yalnızca (daha sonra) ayrı olarak başlatılması için geçerlidir sudo. Zaten çalışan bash işleminizi veya onun soyundan herhangi birini etkilemez.


3

Bu cevapların hepsi muhtemelen doğrudur. Ancak, sudoizin gerektiren bash scriptleri oluşturmak için bu genellikle kullanılan bir yöntem değildir (bildiğim kadarıyla) . Genellikle, betiğin en üstünde sudoizinler ile çalıştırılmadığını varsayıyorsunuz ve bunun yerine sudo -vkendinizi (kullanıcıyı parolalarını soracak) bir sudo'oturum' ayarlamak için çağırıyorsunuz . Ya edebilirsiniz echobazı açıklayıcı istemi önce metnin veya override sudo'ın sahip istemi kendi -panahtarı, izin kullanıcı ihtiyacınız biliyorum sudobazı komutlar için erişim.

Daha sonra, betiğinizde, sudobaşka şifre talep etmeden, gerektiren komutları (ve yalnızca bunu gerektiren komutları) çağırmanız yeterli olacaktır . Komut dosyanızda birlikte çalışan belirli bir komut grubunun (kendi kullanımlarına bakılmaksızın sudo) sudo zaman aşımının ötesine uzanacağını düşünüyorsanız, sudo -vbir tür 'canlı tutma sudo' oturumu yayınlamak için ortada arayabilirsiniz . '.

Eğer sudo'oturum' komut dosyası sırasında geçerliliğini yitirirse, komut dosyasında bir sudo komutu verdiğinizde kullanıcıdan basitçe şifrelerini girmeleri istenir.


1
Senaryonun adımlarından birinin, iki saat sürebilen yepyeni bir linux çekirdeği inşa ettiğini söyleyin. Oturumu canlı tutmak zor olabilir, bununla nasıl başa çıktınız?
Gauthier

Yapamazsın Ancak bir dahaki sefere sudo -vonu tekrar kullanıcı şifresini isteyecektir. Bence en kötü sorun değil. Belki yardımcı olmak, kullanıcıyı mekanizmanın farkında yapmak faydalı olabilir.
alexrussell

Bunun tersi, kullanıcının diğer cevaplara göre betiği sudo ile çağırmasını ve ardından sudo -u $SUDO_USERkök olmayan tüm komutları yükseltmeden çalıştırmasını sağlamaktır. Ne yazık ki daha fazla kod ekler, ancak uzun süren bir süreçte kök işleri yapmak için tek güvenilir yoldur.
dragon788

İçine geçici bir dosya koymak için programın başında bir kez ben açıklamak sanırım, bunu yapmanın başka başka yolu sudo çağırmak olacaktır /etc/sudoers.dkullanarak visudo -c -f /tmp/tempsudoersdosya yerine kopyalamadan önce geçerli olmasını sağlamak için, ve sonra yapılması kez bu dosyayı kaldırmak (tırmanmanın kötüye kullanılmamasını sağlamak için çıkış / hata tuzağı kullanılması). En güvenli ve güvenli uygulama, kullanıcının komut dosyasındaki belirli komutları NOPASSWD, dosyayı oluşturmak için her komutu / argümanı bir diziye depolayarak şifresiz olarak belirli argümanlarla çalıştırmasına izin verir .
dragon788

Burada @Gauthier'e geri dönmek için biraz geç kaldı, ancak sudoverilen tek bir görev zaman aşımından daha uzun sürerse bir oturumu canlı tutamayacağımı söylediğimde yanıldım . Geçen gün Mathias Bynens'in dotfiles deposunda bu teknikle karşılaştım: while true; do sudo -n true; sleep 60; kill -0 "$$" || exit; done 2>/dev/null &- github.com/mathiasbynens/dotfiles/blob/master/.macos#L13
alexrussell
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.