Lokale Linux-Verzeichnisberechtigungen als Fragezeichen für Nicht-Root

Okay, das ist neu. Ich habe solche Fälle mit fehlerhaften Speichergeräten und Fehlern im Remote-Speicher (SAN, NAS) gesehen. Ich glaube, ich habe sogar etwas Ähnliches gesehen, das durch Mount-Berechtigungen verursacht wurde. Aber es ist das erste Mal, dass ich sehe, dass dies auf demselben Dateisystem wie mein Homedir geschieht ...

Ich bin sehr neugierig darauf ... Welche Art von Permisisons treten hier ein? Auf keinen Fall Mounts (ich bin im selben ext4-Dateisystem), nicht SELinux, keine ACLs. Dann was???

Ich erinnere mich nicht, wie dieses Verzeichnis erstellt wurde. Es ist wahrscheinlich, dass es von einer Art Software erstellt wurde.

Für mich ist der seltsamste Teil, dass das Verzeichnis nicht einmal die Informationen seiner oder seiner Eltern sehen darf (letzter Befehl) ...

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 $ 

Attribute:

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 $ 

Bei Dateien reicht das Lesen aus, um die Berechtigungen zu überprüfen. Sie müssen Ordner lesen UND ausführen, um sie zu ls.

chmod -R a+X ./deploy_dir

Großbuchstaben X, um die Ausführung nur für Ordner (und Dateien, für die bereits ein Ausführungsbit gesetzt wurde) festzulegen.

stat(2)Zum Lesen der Berechtigungen einer Datei muss diese aufgerufen werden. Dazu ist die Berechtigung " Ausführen / Zugriff" für das enthaltende Verzeichnis (alle Verzeichnisse im Pfad) erforderlich. Dies ist tatsächlich bei jedem anderen Systemaufruf der Fall, der einen Dateinamen annimmt. Das Lesen des Inhalts eines Verzeichnisses (der Liste der Dateinamen) erfordert jedoch nur Lesezugriff auf das Verzeichnis.

In Ihrem Beispiel-Snippet:

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

lsversuchte anzurufen stat(".../bin/D:/workspace"), bekam einen Fehler und beschwerte sich. Auf einigen Systemen können Sie Teilinformationen aus den readdir/ getdents-Aufrufen zusammen mit den Dateinamen abrufen, ohne diese verwenden zu müssen stat. Wie hier workspacewird gezeigt, um ein Verzeichnis zu sein.

Und hier sehen wir, dass es für keinen Benutzer ein x-Bit gibt:

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

Als root erhalten Sie eine vollständige Liste, da root die Berechtigungsbits vollständig ignoriert.

Um Dateiattribute betrachten zu können, muss man das Verzeichnis lesen können. Ist dies nicht möglich, werden Fragezeichen angezeigt.

Schauen Sie sich die Attribute des Verzeichnisses ( .../D:/.oben) an, um herauszufinden, warum dieser Benutzer die Informationen nicht lesen kann . Eine andere mögliche Ursache wäre, wenn das Verzeichnis aus einem anderen Grund als den Zugriffsmodi entfernt wurde oder nicht zugänglich ist (z. B. Netzwerkdateisystem, veraltetes Handle).

Heute hatte ich ein sehr ähnliches Problem mit ähnlichen Symptomen: Fragezeichen in den Berechtigungs- und Besitzfeldern, und selbst mit root / sudo konnte ich nichts davon ändern. Dann erinnerte ich mich schließlich daran, dass dieses bestimmte Verzeichnis tatsächlich der Mount-Punkt für ein Verzeichnis auf der Windows-Dateifreigabe war, das ich vor einigen Wochen eingerichtet hatte (in einer Testsitzung, um festzustellen, ob Samba / CIFS für mein Projekt gut ist) und anscheinend es wurde in der Zwischenzeit abmontiert. Nach erneuter Ausgabe des mount.cifsBefehls und Eingabe meiner Anmeldeinformationen für den Windows-Teil unseres Netzwerks meldete 'ls' normale Berechtigungs- und Besitzinformationen im Verzeichnis. Da die Symptome genau wie Ihre aussahen, frage ich mich, ob Sie sich in einer ähnlichen Situation befinden, auch weil "D:" sehr Windows-artig aussieht.