¿Alguien puede explicar por qué sudo ls con un comodín no funciona?

$ 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

¿Alguien puede explicar por qué sucede esto? Estoy atrapado en un script debido a esto.

— Faisal
fuente

Respuestas:

Una posibilidad es que no tenga permisos para acceder a uno o más de los directorios en esa ruta ( /sites/servers/server_instance/logs). El shell lleva a cabo la expansión de comodines y luego las rutas expandidas se pasan al sudocomando.

Si su usuario no tiene permisos, la expansión no funcionaría en el primer comando. Se ejecutará tal cual ( ls -ltr /sites/servers/server_instance/logs/access*), y no hay un archivo literalmente llamado access*). Si abctiene los permisos requeridos para todos los directorios en la ruta, el segundo comando, que no tenía comodines, no sería tocado por su shell, y funcionaría bien.

$ 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
fuente

gracias Muru, tu opinión fue correcta, cambié el permiso a 755 y ahora está funcionando bien.

— Faisal

@Faisal: Creo que cambiar los permisos no es el remedio adecuado, aunque revela que el diagnóstico es correcto. El remedio adecuado parece ser no hacer globping mientras se prepara el comando sudo, sino más bien suprimirlo aquí (citando el argumento de ruta), pasando el argumento tal cual al lscomando que puede entonces (cuando el cambio de identidad suha tomado efecto) hacer el globbing.

— Marc van Leeuwen

@MarcvanLeeuwen lsno hace nada.

— Muru

Puede hacer que ocurra el bloqueo en el entorno de sudo agregando sh -ca la línea de comando.

— Stig Hemmer

@Faisal si eso responde a tu pregunta, considera aceptarla ...

— clem steredenn

Es posible que tenga deshabilitado el globbing.

Busque algo como set -fo set -o noglobantes de esas líneas en el script, o si está en un shell interactivo echo $-; si hay un fen la salida, el globbing está deshabilitado:

$ echo $-
fhimBH

Para solucionarlo, elimine set -fo set -o noglobdel script, o si está en un shell interactivo, ejecute set +fo 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
fuente

Sí, yo como mi usuario individual no tengo acceso a ese camino. En script, voy como mi usuario (a través de ssh) y ejecuto ese comando a través del usuario de producción. ¿Hay alguna solución para esto? (Un punto a destacar es que no tengo que dar una contraseña para cambiar de usuario)

— Faisal

@Faisal ¿Qué tal si ejecuta el script como el usuario objetivo ( sudo -u abc /path/to/script)? En ese caso, el globbing no debería fallar. En cualquier caso, muru sugirió el tema del camino en su respuesta, no yo. Debería considerar aceptar su respuesta ( askubuntu.com/help/accepted-answer ).

— kos

En realidad, lo estoy ejecutando en una máquina remota a través de un script, por lo que sería necesario. Gracias a ti también por responder.

— Faisal