Quelqu'un peut-il expliquer pourquoi sudo ls avec un caractère générique ne fonctionne pas?

$ 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

Quelqu'un peut-il expliquer pourquoi cela se produit? Je suis coincé sur un script à cause de cela.

— Faisal
source

Réponses:

Une possibilité est que vous ne disposez pas des autorisations pour accéder à un ou plusieurs des répertoires de ce chemin ( /sites/servers/server_instance/logs). L'extension générique est effectuée par votre shell, puis les chemins étendus sont transmis à la sudocommande.

Si votre utilisateur n'a pas d'autorisations, l'expansion ne fonctionnera pas dans la première commande. Il serait exécuté tel quel ( ls -ltr /sites/servers/server_instance/logs/access*), et il n'y a pas de fichier nommé littéralement access*). Si abcpossède les autorisations requises pour tous les répertoires du chemin, la deuxième commande, qui n'avait pas de caractères génériques, ne serait pas modifiée par votre shell et fonctionnerait correctement.

$ 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

— muru
source

merci Muru, votre opinion était correcte, j'ai changé la permission en 755 et maintenant ça marche bien.

— Faisal

@Faisal: Je pense que changer les permissions n'est pas le bon remède, même si cela révèle que le diagnostic est correct. Le remède approprié semble être de ne pas effectuer de globulation lors de la préparation de la commande sudo, mais plutôt de la supprimer ici (en citant l'argument path), en passant l'argument tel quel à la lscommande qui peut alors (lorsque le changement d'identité de sua pris effet) faire le globbing.

— Marc van Leeuwen

@MarcvanLeeuwen lsne fait aucun globbing.

— muru

Vous pouvez faire en sorte que la globalisation se produise dans l'environnement sudo en ajoutant sh -cà la ligne de commande.

— Stig Hemmer

@Faisal si cela répond à votre question, pensez à l'accepter ...

— clem steredenn

Vous pouvez avoir désactivé la globalisation.

Recherchez quelque chose comme set -fou set -o noglobavant ces lignes dans le script, ou si dans une exécution interactive du shell echo $-; s'il y a un fdans la sortie, la globalisation est désactivée:

$ echo $-
fhimBH

Pour résoudre ce problème, supprimez set -fou set -o noglobdu script, ou si dans une exécution de shell interactive set +fou 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

— kos
source

Oui, en tant qu'utilisateur individuel, je n'ai pas accès à ce chemin. Dans le script, je vais en tant qu'utilisateur (via ssh) et j'exécute cette commande via l'utilisateur de production. Y a-t-il du travail pour cela? (Un point à noter est que je n'ai pas à donner de mot de passe pour changer d'utilisateur)

— Faisal

@Faisal Que diriez-vous d'exécuter le script en tant qu'utilisateur cible ( sudo -u abc /path/to/script)? Dans ce cas, la globalisation ne devrait pas échouer. En tout cas, Muru a suggéré le problème du chemin dans sa réponse, pas moi. Vous devriez envisager d'accepter sa réponse ( askubuntu.com/help/accepted-answer ).

— kos

En fait, je lance cela sur une machine distante via un script, donc -i serait nécessaire. Merci également à vous d'avoir répondu.

— Faisal