Permisos de directorio local de Linux como signos de interrogación para no root

8

Bien, esa es nueva. He visto casos como ese con dispositivos de almacenamiento defectuosos, con fallas en el almacenamiento remoto (SAN, NAS), creo que incluso he visto algo similar causado por los permisos de montaje. Pero es la primera vez que veo que esto sucede en el mismo sistema de archivos que mi homedir ...

Tengo mucha curiosidad sobre eso ... ¿Qué tipo de permisos están pateando aquí? Definitivamente no se monta (estoy en el mismo sistema de archivos ext4), no SELinux, no ACL. ¿¿¿Y que???

No recuerdo cómo se creó este directorio. Es probable que haya sido creado por algún tipo de software.

Para mí, la parte más extraña es que el directorio ni siquiera puede ver su información o la de su padre (último comando) ...

Linux Mint Sarah

user01@MyPC ~/somedirectory $ ls -l ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace': Permission denied
viso 0
d????????? ? ? ? ?            ? workspace
user01@MyPC ~/somedirectory $ ls -ld ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
drw-r--r-- 3 user01 user01 4096 Rgs 27  2016 ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ ls -l ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace': Permission denied
viso 0
d????????? ? ? ? ?            ? workspace
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ 
user01@MyPC ~/somedirectory $ sudo file ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:: directory
user01@MyPC ~/somedirectory $ sudo ls -l ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
viso 4
drwxr-xr-x 3 user01 user01 4096 Rgs 27  2016 workspace
user01@MyPC ~/somedirectory $ sudo stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937216     Links: 3
Access: (0644/drw-r--r--)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:57:33.990819052 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2017-03-13 14:56:40.960468954 +0200
 Birth: -
user01@MyPC ~/somedirectory $ sudo getfacl ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
# file: deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:
# owner: user01
# group: user01
user::rw-
group::r--
other::r--

user01@MyPC ~/somedirectory $ stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937216     Links: 3
Access: (0644/drw-r--r--)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:57:33.990819052 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2017-03-13 14:56:40.960468954 +0200
 Birth: -
user01@MyPC ~/somedirectory $ stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/workspace
stat: nepavyksta patikrinti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace': Permission denied
user01@MyPC ~/somedirectory $ sudo stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/workspace
  File: './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3937217     Links: 3
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 12:58:46.845727190 +0300
Modify: 2016-09-27 11:18:38.309775066 +0300
Change: 2016-12-02 13:56:08.298109826 +0200
 Birth: -
user01@MyPC ~/somedirectory $ stat .
  File: '.'
  Size: 4096        Blocks: 8          IO Block: 4096   aplankas
Device: 807h/2055d  Inode: 3278479     Links: 23
Access: (0755/drwxr-xr-x)  Uid: ( 1000/ user01)   Gid: ( 1000/ user01)
Access: 2017-09-21 09:46:22.102269130 +0300
Modify: 2017-09-20 17:33:04.564009275 +0300
Change: 2017-09-20 17:33:04.564009275 +0300
 Birth: -
user01@MyPC ~/somedirectory $ ll ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace': Permission denied
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/.': Permission denied
ls: negaliu pasiekti './deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/..': Permission denied
viso 0
d????????? ? ? ? ?            ? ./
d????????? ? ? ? ?            ? ../
d????????? ? ? ? ?            ? workspace/
user01@MyPC ~/somedirectory $ 

Atributos:

user01@MyPC ~/somedirectory $ sudo lsattr ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/
-------------e-- ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace
user01@MyPC ~/somedirectory $ sudo lsattr ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D\:/workspace
-------------e-- ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D:/workspace/directory2
user01@MyPC ~/somedirectory $ 
netikras
fuente
¿Cómo se ha montado el sistema de archivos? ¿Qué tipo de sistema de archivos es?
Raman Sailopal
Todo esto está en el mismo sistema de archivos ext4: mi sistema de archivos / home. Se menciona en el post
netikras
2
Por favor no publique imágenes de texto. Y solo muestre la información relevante. ¡Como mínimo, puede eliminar los comandos incorrectos! Es muy difícil seguir la forma en que lo estás mostrando.
terdon
¿Debo editar la publicación?
netikras
2
¿Qué pasa con la posibilidad de un sistema de archivos dañado y la dificultad para leer inodos? ¿Dmesg informa algo?
Raman Sailopal

Respuestas:

17

En los archivos leídos es suficiente para verificar los permisos. Necesita leer Y ejecutar en carpetas para ls.

chmod -R a+X ./deploy_dir

Capital X solo establece ejecutar en carpetas (y archivos que ya tienen bit de ejecución establecido).

Capacho
fuente
55
Una vez pasé medio día en un problema similar, ¡es fácil pasarlo por alto!
HoD
7

Leer los permisos de un archivo requiere invocarlo stat(2), y eso requiere el permiso de ejecución / acceso en el directorio que lo contiene (todos los directorios en la ruta). Esto es realmente lo mismo con todas las demás llamadas al sistema que toman un nombre de archivo. Sin embargo, leer el contenido de un directorio (la lista de nombres de archivo) solo requiere acceso de lectura en el directorio.

En su fragmento de muestra:

~/somedirectory $ ls -l .../bin/D\:
ls: negaliu pasiekti '.../bin/D:/workspace': Permission denied
viso 0
d????????? ? ? ? ?            ? workspace

lsIntenté llamar stat(".../bin/D:/workspace"), recibí un error y me quejé. En algunos sistemas, puede obtener información parcial de las llamadas readdir/ getdentsjunto con los nombres de los archivos, sin necesidad de usarlos stat. Al igual que aquí, workspacese muestra como un directorio.

Y aquí vemos que no hay x bit para ningún usuario:

~/somedirectory $ ls -ld .../bin/D\:
drw-r--r-- 3 user01 user01 4096 Rgs 27  2016 .../bin/D:

Como root, obtienes una lista completa, ya que ser root ignora por completo los bits de permiso.

ilkkachu
fuente
¿Podrías hacer lo mismo, pero LC_ALL=Cexportado a tu entorno?
un CVn
1

Para ver los atributos del archivo, se necesita el derecho de leer el directorio. Si esto no es posible, se mostrarán signos de interrogación.

Por la razón por la cual ese usuario no puede leer la información, mire los atributos del directorio ( .../D:/.arriba). Otra posible causa sería si el directorio se ha eliminado o es inaccesible (por ejemplo, sistema de archivos de red, identificador obsoleto) por un motivo diferente al de los modos de acceso.

Ned64
fuente
Se actualizó la pregunta. Los atributos son todos iguales de D: \, sus hijos, su padre y mi ~ /. directorio.
netikras
Y este directorio ha estado allí durante meses. No está desapareciendo en ningún lado. Se está diciendo claramente que si no me raíz no puede ir por dentro: / que no funcionarían con aleteo de los medios de comunicación o filehandles Creo
netikras
Intente verificar también todos los directorios principales, si alguno de ellos tiene atributos que crean problemas (vea si llfalla como user01en cualquier principal hasta la raíz). No es necesario publicar la salida, solo díganos el resultado por favor.
Ned64
1
Acabo de tararear el directorio, scp'lo a otro servidor e hice la misma lsprueba. El resultado es idéntico
netikras
2
Usted no xusa la bandera, entonces HoD tiene razón. No había visto eso en tu salida desordenada. stracete hubiera dicho eso. también.
Ned64
0

Hoy tuve un problema muy similar, con síntomas similares: signos de interrogación en los campos de permisos y propiedad, e incluso con root / sudo no pude cambiar nada de esto. Luego, finalmente recordé que este directorio en particular era en realidad el punto de montaje para un directorio en el recurso compartido de archivos de Windows, que había configurado hace unas semanas (en una sesión de prueba para ver si Samba / CIFS es bueno para mi proyecto) y aparentemente se desmontó mientras tanto. Después de volver a emitir el mount.cifscomando e ingresar mis credenciales para la parte de Windows de nuestra red, 'ls' informó la información de propiedad y permiso normal en el directorio. Dado que los síntomas se parecen exactamente a los suyos, me pregunto si se encuentra en una situación similar, también porque "D:" se ve muy parecido a Windows.

davino
fuente
Hola, la marca verde significa que el usuario que hizo la pregunta marcó la respuesta como "aceptada". Por lo tanto, al menos podemos suponer que los permisos se pudieron cambiar usando chmod. Este directorio está debajo del directorio de inicio de los usuarios ( ~). Además, ya son conscientes de que problemas como este pueden deberse a problemas de montaje con almacenamiento remoto.
sourcejedi
Tenga en cuenta también que el statcomando confirma esto. Compare el Devicecampo para stat .vs sudo stat ./deploy_dir/liferay-portal-6.1.1-ce-ga2/tomcat-7.0.27/bin/D \: File: './deploy_dir/liferay-portal-6.1.1-ce -ga2 / tomcat-7.0.27 / bin / D: ''. Es lo mismo. Este resultado es una buena evidencia de que están en el mismo sistema de archivos.
sourcejedi
¡Ah bien! Perdón por el ruido ...
davino