W bash 4.3.27 „su” ignoruje zmienne użytkownika podczas łączenia „-” z „-c poleceniem”?


2

Od na zawsze używaliśmy do uruchamiania skryptów użytkownika od innego użytkownika crontab w ten sposób:

00 12 * * 1 su - user2 -c "/home/user2/myscript.sh"

W ten sposób skrypt jest uruchamiany po załadowaniu powłoki interaktywnej ~ / .bash_profile.

Jednak ostatnio załataliśmy Bash do wersji 4.3.27 z powodu luki „shellshock”, która już nie działa.

Nadal mamy kopię starego basha, więc możemy przetestować problem:

[root ~]$ /bin/bash --version
GNU bash, versión 4.3.30(1)-release (x86_64-unknown-linux-gnu)

[root ~]$ /bin/bash.old --version
GNU bash, versión 4.1.2(1)-release (x86_64-redhat-linux-gnu)

[root ~]$ echo "export MYNEWVAR=helo" >> /home/usertest/.bash_profile

[root ~]$ su -s /bin/bash - usertest -c "env | grep MYNEWVAR"
[root ~]$ su -s /bin/bash.old - usertest -c "env | grep MYNEWVAR"
MYNEWVAR=helo

Czy to jest oczekiwane zachowanie? lub przegapiliśmy, aby włączyć niektóre funkcje w skonfigurować kompilacja krokowa?

Pozdrowienia.


Podejrzewam, że coś przeoczyłeś w fazie konfiguracji / kompilacji. Powinieneś być w stanie znaleźć opcje, które twój dostawca użył do skompilowania oryginalnego pliku binarnego, abyś mógł podać te same opcje.
Zoredache

Odpowiedzi:


-1

Zaktualizowane od głosowania obniżającego, więc proszę, jeśli to poprawi problem, tak jak wygląda, gdy użyłem maszyny wirtualnej i archa, zagłosuj, więc otrzymam -1 usuwany.

Jeśli twój system używa SUDO, zobacz drugą połowę poniżej ...

W przypadku systemów używających TYLKO SU:

W niektórych systemach może być aliasowany, więc nawet jeśli użyjesz su, automatycznie użyje su - co wymusza użycie zmiennych nowego użytkownika, które znajdują się w ich bashrc

Spójrz na swój osobisty użytkownik bash.rc, aby znaleźć wspomniany alias poniżej i usunąć go. To powinno powstrzymać go przed próbą użycia zmiennych ustawionych przez użytkownika root.

strona: https://wiki.archlinux.org/index.php/su
Odpowiedni bit:

Administratorzy powinni zatem używać su w następujący sposób:

$ su -

Identyczny wynik jest tworzony przez dodanie nazwy użytkownika root:

$ su - root

Podobnie, to samo można zrobić dla każdego innego użytkownika (np. Dla użytkownika   o nazwie archie):

# su - archie

Możesz do tego dodać alias do ~ / .bashrc:

alias su="su -"

Dla systemów SUDO

To z powodu konfiguracji sudo. Użyłem następującego pytania / odpowiedzi, aby przejść: https://askubuntu.com/questions/128413/setting-the-path-so-it-applies-to-all-users-including-root-sudo

Gruntownie:

Strona podręcznika dla sudoers stwierdza:

   env_reset       If set, sudo will reset the environment to only contain
                   the LOGNAME, MAIL, SHELL, USER, USERNAME and the SUDO_*
                   variables.  Any variables in the caller's environment
                   that match the env_keep and env_check lists are then
                   added.  The default contents of the env_keep and
                   env_check lists are displayed when sudo is run by root
                   with the -V option.  If the secure_path option is set,
                   its value will be used for the PATH environment
                   variable.  This flag is on by default.

i tak to się rozwiązuje:

Możesz więc wykonać następujące czynności, aby zachować zmienne podczas używania sudo

sudo visudo

spowoduje to otwarcie ustawień sudo. Następnie, zgodnie z tym, co zrobiłem, dodajesz poniższe poniżej

Defaults secure_path="blah"

Defaults env_keep +="VARIABLE VARIABLE VARIABLE"

(WYKLUCZAJĄC ŚCIEŻKĘ taką, jaka jest ustawiona przez secure_path) i są to pojedyncze spacje między każdą zmienną, jeśli chcesz zachować więcej niż 1.

a to, co to robi, mówi sudo, które zmienne env należy zachować, a nie lekceważyć.

Gdy skończysz, przytrzymaj ctrl i naciśnij o, aby napisać Out naciśnij Enter i powiedz tak, aby zapisać [nawet jeśli określa plik tmp, jest OK, zostanie zapisany z powrotem do głównej konfiguracji, po prostu powiedz tak, gdy zostaniesz zapytany, czy chcesz zastąpić].

To powinno pozwolić ci na utrzymanie dowolnych zmiennych, które chcesz (duża jest zmienna JAVA_HOME, a także http_proxy, jeśli używasz proxy).

Powinno to wyglądać mniej więcej tak, jak poniżej: określona zmienna:

Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin/bin"
Defaults        env_keep +="GRAILS_HOME"

aby sprawdzić, czy wyjdzie z otwartych okien terminala i ponownie je otworzy i uruchom

echo $GRAILS_HOME 

To powinno być to, co ustawiłeś, teraz problem

sudo echo $GRAILS_HOME

i teraz powinno pozostać niezmienione.

Odniesienie Grails_home pochodzi ode mnie, pomagając innemu użytkownikowi na społecznościach ubuntu, więc po prostu podporządkuj go nazwie twojej zmiennej.


sudo nie jest su, a przynajmniej nie na większości systemów. Nie udostępniają pliku konfiguracyjnego.
Zoredache

To, że sudo jest preferowane, to nieodwracalne. OP pyta, dlaczego binarny su w jego systemie zmienił zachowania po łataniu basha. Jego konfiguracja działała, zmienił się tylko bash. Twoja odpowiedź i te komentarze nie są związane z zadawanym pytaniem.
Zoredache

zaktualizowałem odpowiedź, aby przekazać im te informacje bezpośrednio. Zobacz górną część mojej odpowiedzi, teraz odpowiedziałem na oba systemy tylko dla SU i zostawiłem kawałek Sudo dla tych użytkowników, który był punktem, przez który próbowałem przejść wcześniej, tylko su, jest to zazwyczaj alias w bashrc przepraszam, jeśli nie zrobiłeś przeczytaj to tak, jak zamierzałem. Powinien być teraz znacznie jaśniejszy.
Pariah
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.