Почему мне отказывают в разрешении, когда судишься с пользователем? - PullRequest
Новая
       27

Почему мне отказывают в разрешении, когда судишься с пользователем?

3 голосов
/ 10 мая 2019

Если я su user из моего домашнего каталога, я получаю отказано в разрешении на завершение bash, но если я su user из другого каталога, ошибки нет. 

Can't locate strict.pm:   lib/strict.pm: Permission denied at 
/usr/bin/vendor_perl/bash-complete line 7.
BEGIN failed--compilation aborted at /usr/bin/vendor_perl/bash-complete line 7.

Строка 7 ссылочного файла use strict; ... включена в каждую версию perl, по крайней мере, с конца 90-х.

su user источники /etc/bash.bashrc и пользователь должен .bashrc. Почему местоположение вызывающего пользователя в файловой системе изменит это?

См. мой репо для более подробной информации, но я думаю, что я получил необходимые основы здесь.

Редактировать: подробное описание настройки.

Я добавил следующие строки в /etc/bash.bashrc (где и происходит ошибка): 

if [[ $USER == 'testloginfiles' ]]; then
    echo "/etc/bash.bashrc (-: $-) ($(shopt login_shell))"
    printf '@INC: %s\n' $(perl -e 'print join ":", @INC')
fi

И это вывод, если я нахожусь в моем домашнем каталоге: 

$ pwd;su testloginfiles
/home/harleypig
Password: 
/etc/bash.bashrc (-: himBH) (login_shell        off)
@INC: lib:/usr/lib/perl5/5.28/site_perl:/usr/share/perl5/site_perl:/usr/lib/perl5/5.28/vendor_perl:/usr/share/perl5/vendor_perl:/usr/lib/perl5/5.28/core_perl:/usr/share/perl5/core_perl
Can't locate strict.pm:   lib/strict.pm: Permission denied at /usr/bin/vendor_perl/bash-complete line 7.
BEGIN failed--compilation aborted at /usr/bin/vendor_perl/bash-complete line 7.
/home/testloginfiles/.bashrc (-: himBH) (login_shell        off)
[testloginfiles@sweetums harleypig]$

Если я нахожусь в другом каталоге (например, /tmp), я получаю следующее: 

$ pwd ; su testloginfiles
/tmp
Password: 
/etc/bash.bashrc (-: himBH) (login_shell        off)
@INC: lib:/usr/lib/perl5/5.28/site_perl:/usr/share/perl5/site_perl:/usr/lib/perl5/5.28/vendor_perl:/usr/share/perl5/vendor_perl:/usr/lib/perl5/5.28/core_perl:/usr/share/perl5/core_perl
/home/testloginfiles/.bashrc (-: himBH) (login_shell            off)
[testloginfiles@sweetums tmp]$

Существует относительный путь, как подсказывает @pcronin, но ни в моем домашнем каталоге, ни в /tmp нет каталога lib. Почему один вызывает ошибку, а другой нет?

Ответы [ 2 ]

2 голосов
/ 11 мая 2019

Я недостаточно внимательно читал справочную страницу su. Ответ в первом разделе:

Для обратной совместимости su по умолчанию не изменяет текущий каталог и установить только переменные среды HOME и SHELL (плюс USER и LOGNAME, если целевой пользователь не является пользователем root).

Итак, моя существующая среда, которая включала PERL5LIB=lib. был оставлен на месте. /etc/bash.bashrc выполняется с любым окружением, которое у меня есть. Это кажется возможным риском для безопасности.

В любом случае, следующее решило проблему, хотя это все еще не объясняет, почему он только выдавал ошибку из моего домашнего каталога: 

$ pwd ; PERL5LIB= su testloginfiles
/home/harleypig
Password: 
/etc/bash.bashrc (-: himBH) (login_shell        off)
@INC: /usr/lib/perl5/5.28/site_perl:/usr/share/perl5/site_perl:/usr/lib/perl5/5.28/vendor_perl:/usr/share/perl5/vendor_perl:/usr/lib/perl5/5.28/core_perl:/usr/share/perl5/core_perl
/home/testloginfiles/.bashrc (-: himBH) (login_shell            off)
[testloginfiles@sweetums harleypig]$
2 голосов
/ 11 мая 2019

  1. В Perl use strict говорит Perl, что нужно искать, загружать и импортировать символы из файла с именем strict.pm. Это делается путем поиска упорядоченного списка каталогов в списке @INC. См. этот ответ для получения дополнительной информации о том, как это происходит. Наблюдаемая ошибка указывает на то, что перед успешным поиском strict.pm perl искал путь, к которому у исполняющего пользователя (вероятно, testloginfiles) не было доступа.

  2. На содержимое @INC могут влиять как каталог, из которого запускается скрипт, так и переменные среды. В вашем случае, так как проблема проявляется, когда программа запускается из одного каталога, но не из другого, вполне вероятно, что одна (или более) из записей в @INC является относительным путем, например lib (вместо чего-то как /usr/share/perl5), или что переменная среды, которая может влиять на список @INC perl, отличается в среде целевого пользователя.

  3. Запуск perl -E 'print join("\n", @INC)'; выдаст список местоположений, которые он будет искать. Запустите его в командной оболочке обычного пользователя и сравните результаты с тем, что произойдет, если вы добавите его в файл .bashrc testloginfiles. Разница в результатах должна объяснять разницу в поведении.

UPDATE

  1. С новой информацией, которую вы предоставили, мы видим, что нет никаких отличий в @INC, что позволяет нам понять, как два случая по-разному интерпретируют @INC. Как вы обнаружили на справочной странице su, su не меняет текущий каталог, что означает, что относительные пути не будут влиять на интерпретацию @INC. Но su меняет пользователя, поэтому это означает, что пользователь su'd проверяет, существует ли /home/harleypig/lib/strict.pm. Могу поспорить, что у пользователя su'd нет прав на чтение в домашнем каталоге harleypig, чтобы проверить, существует ли этот файл, что вызывает ошибку.
...