Кто-нибудь может объяснить, почему sudo ls с подстановочным знаком не работает?

$ sudo -iu abc ls -ltr /sites/servers/server_instance/logs/access*
ls: cannot access /sites/servers/server_instance/logs/access*: No such file or directory

$ sudo -iu abc ls -ltr /sites/servers/server_instance/logs/
total 594812
-rwxrwxrwx 1 abc abc      45 Mar 21 12:42 old.log
-rwxrwxrwx 1 abc abc      304537970 Mar 24 12:45 console.log
-rwxrwxrwx 1 abc abc      304537970 Mar 24 13:20 access_nginx.log

Кто-нибудь может объяснить, почему это происходит? Я застрял в сценарии из-за этого.

— Фейсал
источник

Ответы:

Возможно, у вас нет прав доступа к одному или нескольким каталогам в этом пути ( /sites/servers/server_instance/logs). Расширение с подстановочными знаками выполняется вашей оболочкой, а затем расширенные пути передаются sudoкоманде.

Если у вашего пользователя нет прав, расширение не будет работать в первой команде. Это будет выполнено как есть ( ls -ltr /sites/servers/server_instance/logs/access*), и нет файла с буквальным именем access*). Если у abcвас есть необходимые разрешения для всех каталогов в пути, вторая команда, которая не имеет подстановочных знаков, не будет затронута вашей оболочкой, и она будет работать нормально.

$ sudo namei -lx foo/bar/baz
f: foo/bar/baz
drwxr-xr-x muru    muru    foo
drwx------ test    test    bar
drwxr-xr-x muru    muru    baz

$ sudo ls foo/bar/b*
ls: cannot access 'foo/bar/b*': No such file or directory

$ sudo -u test ls foo/bar/
baz

— Мур
источник

спасибо Муру, ваше мнение было верным, я изменил разрешение на 755 и теперь оно работает нормально.

— Фейсал

@Faisal: я думаю, что изменение разрешений не является правильным средством, хотя оно показывает, что диагноз правильный. Правильное средство , казалось бы, не делать подстановку при подготовке команды SUDO, а подавить его здесь (цитируя аргумент пути), передавая аргумент как есть в lsкоманду , которая может затем (когда изменение тождественного suпринял эффект) сделать скованность.

— Марк ван Леувен

@MarcvanLeeuwen lsничего не делает.

— Муру

Вы можете сделать так, чтобы глобирование происходило в среде sudo, добавляя sh -cв командную строку.

— Стиг Хеммер

@Faisal, если это ответит на твой вопрос, подумай о том, чтобы принять его ...

— clem Steredenn

Возможно, у вас отключена глобализация.

Ищите что-то вроде set -fили set -o noglobперед этими строками в скрипте, или если в интерактивной оболочке запустите echo $-; если fв выводе есть глобализация, то отключить:

$ echo $-
fhimBH

Чтобы это исправить, удалите set -fили set -o noglobиз скрипта, или если в интерактивной оболочке запустите set +fили set +o noglob:

$ set -f
$ echo $-
fhimBH
$ ls access*
ls: cannot access access*: No such file or directory
$ set +f
$ echo $-
himBH
$ ls access*
access

— кос
источник

Да, я как мой отдельный пользователь не имею доступа к этому пути. В сценарии я иду как мой пользователь (через ssh) и запускаю эту команду через производственного пользователя. Есть ли работа вокруг этого? (Следует отметить, что мне не нужно давать пароль для смены пользователя)

— Faisal

@Faisal Как насчет запуска сценария от имени целевого пользователя ( sudo -u abc /path/to/script)? В этом случае шатание не должно провалиться. В любом случае, Муру предложил ответ на вопрос о пути, а не я. Вы должны рассмотреть вопрос о принятии его ответа ( askubuntu.com/help/accepted-answer ).

— Кос

На самом деле я запускаю это на удаленной машине через скрипт, так что -i будет необходимо. Спасибо вам и за ответы.

— Фейсал