Sudo ve su üzerinden çalışırken PATH değişkenleri neden farklı?

Fedora VM'mde, kullanıcı hesabımla çalışırken /usr/local/binyolumda var:

[justin@justin-fedora12 ~]$ env | grep PATH
 PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

Ve aynı zamanda çalıştırırken su:

[justin@justin-fedora12 ~]$ su -
Password: 
[root@justin-fedora12 justin]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

Ancak, üzerinden çalışırken sudo, bu dizin yolda değil:

[root@justin-fedora12 justin]# exit
[justin@justin-fedora12 ~]$ sudo bash
[root@justin-fedora12 ~]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/sbin:/bin:/usr/sbin:/usr/bin

Yol üzerinden çalışırken neden farklı olabilir sudo?

Bir göz atın /etc/sudoers. Fedora'daki (RHEL ve ayrıca Ubuntu ve benzeri) varsayılan dosya bu satırı içerir:

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

Bu, sudo altında ikili dosyaları çalıştırırken yolunuzun temiz olmasını sağlar. Bu , bu soruda belirtilen kaygıların bir kısmına karşı korunmaya yardımcı olur . Eğer yoksa Ayrıca uygundur /sbinve /usr/sbinkendi yolunda.

Komut su -, kök kullanıcı profilini yürütecek ve yol vb. Dahil olmak üzere bu kullanıcının ortamını üstlenecektir sudo.

Onun gibi sudodavranmak istiyorsanız , kullanıcının profilini su -uygulayacak seçeneği kullanınsudo -i [command

Gibi su -davranmak istiyorsanız sudo, kısa çizgi kullanmayın - sadece kullanınsu [command]

Nedenini (farklı) çalıştırarak kontrol edebilirsiniz sudo sudo -V.

Örneğin Linux çalıştırmasında:

$ sudo sudo -V | grep PATH
Value to override user's $PATH with: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

^{Not: Açık MacOS / BSD, sadece çalıştırın: sudo sudo -V.}

Bazı Linux dağıtımlarında varsayılan güvenlik politikası eklentisi nedeniyle yukarıdaki liste kısıtlanmıştır.

Bu daha ayrıntılı olarak açıklanmıştır man sudoers:

Eğer secure_pathseçenek ayarlanırsa, değeri için kullanılacak PATHortam değişkeni.

secure_path- Her komut için sudo'dan çalıştırılan yol. Sudo çalıştıran insanlara aklı başında bir PATHortam değişkenine sahip olmalarına güvenmiyorsanız, bunu kullanmak isteyebilirsiniz.

Başka bir kullanım, “kök yolun” “kullanıcı yolundan” ayrı olmasını istiyorsanız. exempt_groupSeçenek tarafından belirtilen gruptaki kullanıcılar bundan etkilenmez secure_path. Bu seçenek varsayılan olarak ayarlanmamış.

Bu durumda, sudo visudoyapılandırma dosyasını çalıştırarak ve düzenleyerek ve değiştirerek secure_path(ayrı yol ekleyerek :) veya kullanıcıyı içine ekleyerek exempt_group( secure_pathseçeneklerden etkilenmeyeceksiniz ) değiştirebilirsiniz.

Veya kullanıcının PATHgeçici mesajını geçmek için koşabilirsiniz:

sudo env PATH="$PATH" my_command

ve şunu kontrol edebilirsiniz:

sudo env PATH="$PATH" env | grep ^PATH

Ayrıca bkz: Nasıl yapmak sudokorumak $PATH?

Ortamın farklı olmasının diğer bir nedeni de, dosyanızda etkin seçeneği etkinleştirilmiş sudoolmanız olabilir . Bu, komutların yeni, minimal bir ortamla yürütülmesine neden olur.env_resetsudoers

Bu nedenle , kullanıcı ortam değişkenlerinizi korumak için env_keepseçeneği ( güvenlik nedeniyle önerilmez ) kullanabilirsiniz:

Defaults        env_reset
Defaults        env_keep += "PATH PYTHONPATH"

Çoğu linux'ta, programları paket yönetimi aracılığıyla yükler ve düzenli olarak güncellemeler alırsınız. Paket yönetimini çevreleyen bir şey kurarsanız, / usr / local / bin dizinine (örneğin veya ... / sbin veya / opt) yüklenir ve düzenli güncellemeler alınmaz.

Bu nedenle, programların bu kadar güvenli olduğu düşünülmüyor ve varsayılan olarak PATH köklerine yerleştirilmiyor.

Bunu sadece kendim için denedim ve görmekte olduğunuz davranışı görmedim - yolum aynı kaldı, bu yüzden belki de sudo yapılandırmanız farklı. Kontrol man sudoersederseniz, secure_pathsıfırlanan denilen bir seçenek olduğunu göreceksiniz PATH- bu seçenek etkin olmuş gibi görünmektedir.

Çünkü kullandığınızda sudo bash, bashgiriş kabuğu gibi davranmaz. İle tekrar deneyin sudo bash -lve aynı sonucu görmelisiniz su -.

Bu doğru ise, o zaman farkı PATHyapılandırma dosyalarında yalanlar: /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profileiken, bir giriş kabuğu için (bu sırayla) yürütülür ~/.bashrcolmayan bir giriş etkileşimli kabuk için yürütülür.

Eski soru, biliyorum, ama şimdi tam buraya girdim çünkü tam olarak bu sorunu araştırıyordum.

Bazı nedenlerden /usr/local/bindolayı sadece kök yoluyla olurken PATH'taydı sudo su -. Kullanırken sudo -iorada değildi. Tabii ki şimdi / etc / sudoers 'a ekleyebileceğimi biliyorum ama bu hala neden orada olduğunu açıklayamadı su -. PATH'ın bu kısmı nereden geldi?

Çok fazla grepping ve araştırdıktan sonra cevabı buldum:

'/ Usr / local / bin' içeren varsayılan yol aslında su (1) 'de kodlanmış.

Bu nedenle, seçmeli olarak bu öğenin seçilmesinden pam yapılandırması, profil, bashrc veya hiçbir şey sorumlu değildi. Devralındığında her zaman zaten oradaydı su. Ve sudohiç çağırmaz su, ancak kendi yapılandırmasını kullanır, çünkü sonrasudo -i

Bunun RHEL6 ve RHEL7'de doğru olduğunu buldum. Başka bir sürümü veya dağıtımı kontrol etmedim.