Jak zezwolić użytkownikowi na zachowanie środowiska dzięki sudo?

17

Występuje następujący błąd, który próbuje umożliwić niektórym zmiennym środowiskowym przejście do nowego środowiska podczas działania sudo:

sudo: sorry, you are not allowed to preserve the environment

Niektóre informacje, które mogą być pomocne przy debugowaniu:

[deploy@worker1 ~]$ sudo -l
    Matching Defaults entries for deploy on this host:
    requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET
    XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin, env_keep+="GIT_WORK_TREE GIT_DIR", !requiretty

User deploy may run the following commands on this host:
    (ALL) NOPASSWD: /usr/bin/git, (ALL) /etc/init.d/httpd*, (ALL) /sbin/service, (ALL) /usr/bin/make, (ALL) /bin/echo

Mój przykładowy bieg:

[deploy@worker1 ~]$ export GIT_DIR="/home/ashinn/testing"
[deploy@worker1 ~]$ sudo -E sh -c 'echo "$GIT_DIR"'
sudo: sorry, you are not allowed to preserve the environment

Mój plik sudoers.d dla tej konkretnej konfiguracji:

Defaults:deploy         env_keep += "GIT_WORK_TREE GIT_DIR", !requiretty
deploy  ALL=(ALL)       NOPASSWD: /usr/bin/git, /etc/init.d/httpd*, /sbin/service, /usr/bin/make, /bin/echo

Próbowałem również dodać !env_resetdo ustawień domyślnych i nadal nie udaje się z tym samym błędem. Czuję, że brakuje mi czegoś oczywistego i potrzebuję drugiego zestawu oczu. Czego tu brakuje?

sudo sudoers

— Andy Shinn
źródło

1

Uważam, że około 93% z nas rozumie sens twojego pytania, ale twoje przykładowe polecenie nie jest zbyt dobre. , jeśli nie zawiedzie całkowicie, wyświetli wartość wstępną , ponieważ powłoka rozszerza zmienną w linii poleceń, zanim jeszcze zostanie wywołana. Lepsze testy to lub, lub , gdzie faktycznie patrzymy na środowisko procesu, który działa uprzywilejowany. sudo (option(s)) echo $GIT_DIRsudo$GIT_DIRsudosudo printenv GIT_DIRsudo env | grep GIT_DIRsudo sh -c 'echo "$GIT_DIR"'

— G-Man mówi „Przywróć Monikę”

Zobacz także to pytanie na temat przepełnienia stosu .

— Franklin Yu,

27

Możesz użyć SETENV„Tag” w swoim sudoerspliku, jak w:

deploy  ALL=(ALL)       SETENV: /usr/bin/git, /etc/init.d/httpd*, /sbin/service, /usr/bin/make, /bin/echo

Lub, aby połączyć to z NOPASSWD:

deploy  ALL=(ALL)       NOPASSWD:SETENV: /usr/bin/git, /etc/init.d/httpd*, /sbin/service, /usr/bin/make, /bin/echo

Odpowiedni fragment człowieka sudoers:

SETENV i NOSETENV

Te tagi zastępują wartość opcji setenv dla poszczególnych poleceń. Zauważ, że jeśli dla polecenia ustawiono SETENV, użytkownik może wyłączyć opcję env_reset z wiersza poleceń za pomocą opcji -E. Dodatkowo zmienne środowiskowe ustawione w linii poleceń, nie podlegają ograniczeniom nałożonym przez env_check, env_deletelub env_keep. W związku z tym tylko zaufani użytkownicy powinni mieć możliwość ustawiania zmiennych w ten sposób. Jeśli dopasowanym poleceniem jest WSZYSTKO, dla tego polecenia sugerowany jest znacznik SETENV; to ustawienie domyślne można zastąpić za pomocą znacznika NOSETENV.

— iodbh
źródło

1

Nie określaj -Eopcji. Korzystanie -Eyou're mówiąc, że wszystkie zmienne środowiskowe dla użytkownika deploypowinny zostać zachowane, a nie tylkoGIT_DIR

Bieganie sudo echo $GIT_DIRpowinno działać, ponieważ dodałeś GIT_DIRdo env_keeplisty

— Stian S.
źródło