Existe-t-il un fichier qui existe toujours et un utilisateur «normal» ne peut pas le créer?

J'en ai besoin pour un test unitaire. Il y a une fonction qui lstat sur le chemin du fichier passé comme paramètre. Je dois déclencher le chemin de code où lelstat échoue (car la couverture du code doit atteindre 90%)

Le test ne peut s'exécuter que sous un seul utilisateur, donc je me demandais s'il y avait un fichier dans Ubuntu qui existe toujours, mais les utilisateurs normaux n'y ont pas accès en lecture ni dans son dossier. (Donclstat échouerait donc à moins d'être exécuté en tant que root.)

Un fichier inexistant n'est pas une solution, car il existe un chemin de code distinct pour cela, que je déclenche déjà.

EDIT: Le manque d'accès en lecture au fichier n'est pas suffisant. Avec cela lstatpeut toujours être exécuté. J'ai pu le déclencher (sur ma machine locale, où j'ai un accès root), en créant un dossier dans / root et un fichier dedans. Et en définissant l'autorisation 700 sur le dossier. Je recherche donc un fichier qui se trouve dans un dossier qui n'est accessible que par root.

Sur les systèmes Linux modernes, vous devriez pouvoir utiliser /proc/1/fdinfo/0(informations pour le descripteur de fichier 1 (stdout) du processus de l'id 1 ( initdans l'espace de noms pid racine qui doit s'exécuter commeroot )).

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'

(supprimez -type fsi vous ne souhaitez pas vous limiter aux fichiers normaux).

/var/cache/ldconfig/aux-cacheest un autre candidat potentiel si vous n'avez qu'à considérer les systèmes Ubuntu. Il devrait fonctionner sur la plupart des systèmes GNU car il /var/cache/ldconfigest créé en lecture + écriture + consultable à la racine uniquement par la ldconfigcommande fournie avec la libc GNU.

En consultant la page de manuel lstat (2) , vous pouvez vous inspirer des cas susceptibles de provoquer l'échec avec des erreurs autres que ENOENT (le fichier n'existe pas.)

Le plus évident est:

EACCES L' autorisation de recherche est refusée pour l'un des répertoires du préfixe de chemin d' accès path .

Vous avez donc besoin d'un répertoire que vous ne pouvez pas rechercher.

Oui, vous pouvez en chercher un qui est déjà dans votre système (peut /var/lib/private- être s'il existe?) Mais vous pourriez aussi bien 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 la chmod -xsuppression des autorisations d'exécution serait suffisante, 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 regardant sa page de manuel:

ENOTDIR Un composant du préfixe de chemin d' accès de chemin d' accès n'est pas un répertoire.

Donc, essayer d'accéder à un fichier tel que /etc/passwd/nonexistentdevrait déclencher cette erreur, qui est encore différente de ENOENT ("Aucun fichier ou répertoire") et pourrait répondre à vos besoins.

Un autre est:

Le chemin ENAMETOOLONG est trop long.

Mais vous pourriez avoir besoin d'un nom très long pour celui-ci (je pense que 4 096 octets est la limite typique, mais votre système / système de fichiers peut en avoir un plus long.)

Enfin, il est difficile de dire si l'un de ces éléments vous sera réellement utile. 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 nombreuses vérifications de niveau supérieur interpréteront simplement les erreurs de lstat (2) comme «n'existe pas». Par exemple, test -eou 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 un bon moyen de renvoyer un message d'erreur différent et ne pas renvoyer une erreur impliquerait que le fichier existe, ce qui n'est certainement pas le cas.

Vous pouvez le findfaire vous-même.

En utilisant /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 un groupe moins restrictif et autoriser root(seul l'utilisateur rootdoit être membre du groupe root), et rechercher 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

Éditer:

En fonction de 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 perm en lecture-écriture-exécution pour others ( o-rwx) et qui appartiennent à root:root.

Techniquement, juste l'absence du xbit execute ( ) empêcherait une liste de répertoires ( lstat(2)) sur le répertoire.

Dans la sortie que j'ai trouvée /run/systemd/inaccessible/sur mon système basé sur l'init Systemd.

En ce qui concerne les fichiers /proc, /sys, /dev:

• Ces systèmes de fichiers sont virtuels FS c'est-à-dire qu'ils résident sur la mémoire, pas sur le disque

• Si vous prévoyez de vous fier à /proc, utilisez par /proc/1/exemple compter sur quelque chose sous PID 1, et non à des PID ultérieurs pour avoir une fiabilité / cohérence car les PID (processus) ultérieurs ne sont pas garantis d'exister.