Sur les systèmes Linux modernes, vous devriez pouvoir utiliser /proc/1/fdinfo/0 (information pour le descripteur de fichier 1 (stdout) du processus d'id 1 (init dans l'espace de noms root pid qui devrait s'exécuter en tant que root )).
Vous pouvez trouver une liste avec (en tant qu'utilisateur normal) :
sudo find /etc /dev /sys /proc -type f -print0 |
perl -l -0ne 'print unless lstat'
(supprimer -type f si vous ne souhaitez pas vous limiter aux fichiers normaux).
/var/cache/ldconfig/aux-cache est un autre candidat potentiel si vous ne devez considérer que les systèmes Ubuntu. Cela devrait fonctionner sur la plupart des systèmes GNU en tant que /var/cache/ldconfig est créé en lecture+écriture+recherchable à la racine uniquement par le ldconfig commande fournie avec la libc GNU.
En regardant la page de manuel lstat(2), vous pouvez vous inspirer des cas qui pourraient le faire échouer avec des erreurs autres que ENOENT (le fichier n'existe pas.)
La plus évidente est :
EACCÈS L'autorisation de recherche est refusée pour l'un des répertoires dans le préfixe de chemin de path .
Vous avez donc besoin d'un répertoire dans lequel vous ne pouvez pas effectuer de recherche.
Oui, vous pouvez en rechercher un qui est déjà dans votre système (peut-être /var/lib/private s'il existe ?) Mais autant en créer un vous-même, avec l'équivalent de :
$ mkdir myprivatedir
$ touch myprivatedir/myunreachablefile
$ chmod 0 myprivatedir
$ ls -l myprivatedir/myunreachablefile
L'opération lstat(2) échouera avec EACCES ici. (La suppression de toutes les autorisations du répertoire garantit cela. Peut-être que vous n'en avez même pas besoin et chmod -x supprimer les autorisations d'exécution serait suffisant, car les autorisations d'exécution sur un répertoire sont nécessaires pour accéder aux fichiers qu'il contient.)
Il existe une autre façon créative de faire échouer lstat(2), en consultant sa page de manuel :
ENOTDIR Un composant du préfixe de chemin de path n'est pas un répertoire.
Donc, essayer d'accéder à un fichier tel que /etc/passwd/nonexistent devrait déclencher cette erreur, qui est encore une fois différente de ENOENT ("Aucun fichier ou répertoire de ce type") et peut répondre à vos besoins.
Un autre est :
ENAMETOOLONG chemin est trop long.
Mais vous pourriez avoir besoin d'un nom très long pour celui-ci (je crois que 4 096 octets est la limite typique, mais votre système/système de fichiers pourrait en avoir un plus long.)
Enfin, il est difficile de dire si l'un d'entre eux sera réellement utile pour vous. Vous dites que vous voulez quelque chose qui ne déclenche pas le scénario "le fichier n'existe pas". Bien que cela signifie généralement une erreur ENOENT, dans la pratique, de nombreux contrôles de niveau supérieur interpréteront simplement toutes les erreurs de lstat(2) comme "n'existe pas". Par exemple test -e ou l'équivalent [ -e ...] du shell pourrait simplement interpréter tout ce qui précède comme "n'existe pas", d'autant plus qu'il n'a pas de bon moyen de renvoyer un message d'erreur différent et que ne pas renvoyer d'erreur impliquerait que le fichier existe, ce qui n'est certainement pas le cas.
Vous pouvez find faites-le vous-même.
Utilisation de /etc -- le répertoire des fichiers de configuration comme point de départ :
sudo find /etc -type f -perm 0400 -user root
Sur mon système, cela ne renvoie rien.
Vous pouvez être moins restrictif et autoriser le groupe root (seulement utilisateur root doit être membre du groupe root ), et recherchez une autorisation de 440 :
sudo find /etc -perm 0440 -user root -group root
Sur mon système, cela renvoie :
/etc/sudoers.d/README
/etc/sudoers
Modifier :
D'après votre modification, vous recherchez un répertoire qui ne dispose pas des autorisations suffisantes pour que l'utilisateur appelant empêche la liste des répertoires :
sudo find / -perm o-rwx -type d -user root -group root
ici je cherche des répertoires (-type d ) qui n'ont pas les bits permanents de lecture-écriture-exécution pour les autres (o-rwx ) et appartient à root:root .
Techniquement, juste l'absence d'exécution (x ) bit empêcherait une liste de répertoires (lstat(2) ) sur le répertoire.
Dans la sortie, j'ai trouvé /run/systemd/inaccessible/ sur mon système basé sur Systemd init.
Concernant les fichiers en /proc , /sys , /dev :
-
Ces systèmes de fichiers sont des FS virtuels, c'est-à-dire qu'ils résident en mémoire et non sur disque
-
Si vous prévoyez de compter sur
/proc, utilisez/proc/1/c'est-à-dire compter sur quelque chose sous le PID 1, et non sur les PID ultérieurs pour avoir une fiabilité/cohérence car l'existence des PID (processus) ultérieurs n'est pas garantie.