Autorisations du répertoire local Linux comme points d'interrogation pour les non-root

8

D'accord, c'est un nouveau. J'ai vu des cas comme ça avec des périphériques de stockage défectueux, avec des défauts de stockage à distance (SAN, NAS), je pense que j'ai même vu quelque chose de similaire causé par des autorisations de montage. Mais c'est la première fois que je vois cela se produire sur le même système de fichiers que mon homedir ...

Je suis très curieux à ce sujet ... Quel genre de permissions entrent en jeu ici? Certainement pas à monter (je suis sur le même système de fichiers ext4), ni SELinux, ni ACL. Alors quoi ???

Je ne me souviens pas comment ce répertoire a été créé. Il est probable qu'il ait été créé par une sorte de logiciel.

Pour moi, la partie la plus étrange est que le répertoire n'est même pas autorisé à voir ses informations ou celles de ses parents (dernière commande) ...

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 $

Les attributs:

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 $

permissions filesystems directory

— netikras
source

Comment le système de fichiers a-t-il été monté? De quel type de système de fichiers s'agit-il?

— Raman Sailopal

Tout cela est sur le même système de fichiers ext4 - mon système de fichiers / home. Il est mentionné dans le post

— netikras

2

Veuillez ne pas publier d'images de texte. Et veuillez ne montrer que les informations pertinentes. À tout le moins, vous pouvez supprimer les mauvaises commandes! C'est très difficile de suivre la façon dont vous le montrez.

— terdon

dois-je modifier le message?

— netikras

2

Qu'en est-il de la possibilité d'un système de fichiers corrompu et de la difficulté à lire les inodes? Dmesg rapporte-t-il quelque chose?

— Raman Sailopal

17

Sur les fichiers lus suffit pour vérifier les permissions. Vous devez lire ET exécuter sur les dossiers pour les ls.

chmod -R a+X ./deploy_dir

Capital X pour définir uniquement l'exécution sur les dossiers (et les fichiers qui ont déjà un ensemble de bits d'exécution).

— Hotte
source

5

J'ai passé une demi-journée sur un problème similaire, c'est facile à manquer!

— HoD

7

La lecture des autorisations d'un fichier nécessite de l'appeler stat(2), et cela nécessite l'autorisation d'exécution / d'accès sur le répertoire contenant (tous les répertoires du chemin). C'est en fait la même chose avec tous les autres appels système qui prennent un nom de fichier. Cependant, la lecture du contenu d'un répertoire (la liste des noms de fichiers) nécessite uniquement un accès en lecture sur le répertoire.

Dans votre extrait de code:

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

lsessayé d'appeler stat(".../bin/D:/workspace"), a obtenu une erreur et s'est plaint. Sur certains systèmes, vous pouvez obtenir des informations partielles des appels readdir/ getdentsainsi que les noms de fichiers, sans avoir besoin de les utiliser stat. Comme ici, workspacese révèle être un répertoire.

Et ici, nous voyons qu'il n'y a pas de bit x pour n'importe quel utilisateur:

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

En tant que root, vous obtenez une liste complète, car être root ignore entièrement les bits d'autorisation.

— ilkkachu
source

Pourriez-vous peut-être faire la même chose, mais en LC_ALL=Cexportant à la place dans votre environnement?

— un CVn le

1

Pour regarder les attributs de fichier, il faut avoir le droit de lire le répertoire. Si cela n'est pas possible, des points d'interrogation seront affichés.

Pour la raison pour laquelle cet utilisateur ne peut pas lire les informations, regardez les attributs du répertoire ( .../D:/.ci-dessus). Une autre cause possible serait si le répertoire a été supprimé ou est inaccessible (par exemple, système de fichiers réseau, descripteur périmé) pour une raison différente des modes d'accès.

— Ned64
source

Mis à jour la question. Les attributs sont tous les mêmes du D: \, ses enfants, son parent et mon ~ /. annuaire.

— netikras

Et ce répertoire existe depuis des mois maintenant. Ça ne disparaît nulle part. Il est clair que si je ne suis pas root, je ne peux pas entrer à l'intérieur: / Cela ne fonctionnerait pas avec les médias ou les

— descripteurs de

Essayez également de vérifier tous les répertoires parents, si l'un d'entre eux a des attributs qui créent des problèmes (voir si lléchoue comme user01sur n'importe quel parent jusqu'à la racine). Pas besoin de publier la sortie, dites-nous simplement le résultat s'il vous plaît.

— Ned64

1

Je viens de tarer le répertoire, de le scper sur un autre serveur et de faire le même lstest. Le résultat est identique

— netikras

2

Vous n'avez pas le xdrapeau, donc HoD a raison. Je n'avais pas vu cela dans votre sortie encombrée. stracevous l'aurait dit. aussi.

— Ned64

0

Aujourd'hui, j'ai eu un problème très similaire, avec des symptômes similaires: des points d'interrogation dans les champs d'autorisation et de propriété, et même avec root / sudo, je n'ai pas pu changer quoi que ce soit. Ensuite, je me suis finalement souvenu que ce répertoire particulier était en fait le point de montage d'un répertoire sur le partage de fichiers Windows, que j'avais installé il y a quelques semaines (lors d'une session d'essai pour voir si Samba / CIFS était bon pour mon projet) et apparemment il a été démonté entre-temps. Après avoir réexécuté la mount.cifscommande et entré mes informations d'identification pour la partie Windows de notre réseau, «ls» a signalé des informations de permission et de propriété normales sur le répertoire. Étant donné que les symptômes ressemblaient exactement aux vôtres, je me demande si vous êtes dans une situation similaire, également parce que "D:" ressemble beaucoup à Windows.

— davino
source

Bonjour, la coche verte signifie que l'utilisateur qui a posé la question a marqué la réponse comme "acceptée". Par conséquent, nous pouvons au moins supposer que les autorisations ont pu être modifiées à l'aide de chmod. Ce répertoire se trouve sous le répertoire personnel des utilisateurs ( ~). De plus, ils savent déjà que des problèmes comme celui-ci peuvent être dus à des problèmes de montage avec le stockage distant.

— sourcejedi

Notez également que la statcommande le confirme. Comparez le Devicechamp pour 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: ''. C'est le même. Cette sortie est une bonne preuve qu'ils sont sur le même système de fichiers.

— sourcejedi

Ah, c'est vrai! Désolé pour le bruit ...

— davino