Есть ли файл, который существует всегда, и "нормальный" пользователь не может его lstat?
Если у вас есть установочный диск Arch, вы можете загрузиться с него, смонтировать установочный раздел и использовать pacstrap для установки dhcpcd, аналогично тому, как вы устанавливали Arch в первый раз.
например,
mount /dev/sda1 /mnt
pacstrap /mnt dhcpcd
В современных системах Linuxвы должны иметь возможность использовать информацию/proc/1/fdinfo/0(для файлового дескриптора 1 (stdout )процесса с идентификатором 1(initв корневом пространстве имен pid, который должен работать какroot)).
Вы можете найти список с помощью (как обычный пользователь):
sudo find /etc /dev /sys /proc -type f -print0 |
perl -l -0ne 'print unless lstat'
(удалите -type f, если вы не хотите ограничиваться обычными файлами ).
/var/cache/ldconfig/aux-cache— еще один потенциальный кандидат, если вам нужно рассматривать только системы Ubuntu. Он должен работать на большинстве систем GNU, так как /var/cache/ldconfigсоздается для чтения+записи+поиска для root только с помощью команды ldconfig, которая поставляется с GNU libc.
Вы можете findсделать это самостоятельно.
Использование/etc--каталога файлов конфигурации в качестве отправной точки:
sudo find /etc -type f -perm 0400 -user root
В моей системе это ничего не возвращает.
Вы можете установить менее строгие ограничения и разрешить группеroot(только пользователь rootдолжен быть членом группы root),и ищите разрешение440:
sudo find /etc -perm 0440 -user root -group root
В моей системе возвращается:
/etc/sudoers.d/README
/etc/sudoers
Редактировать:
Судя по вашему редактированию, вы ищете каталог, который не имеет достаточных прав для вызывающего пользователя, чтобы запретить вывод списка каталогов:
sudo find / -perm o-rwx -type d -user root -group root
здесь я ищу каталоги (-type d), в которых отсутствуют права на чтение -запись -выполнение разрешенных битов для других(o-rwx)и принадлежат root:root.
Технически, простое отсутствие бита выполнения(x)помешало бы отображению каталога(lstat(2))в каталоге.
В выводе я обнаружил /run/systemd/inaccessible/в своей системе, основанной на инициализации Systemd.
О файлах в /proc, /sys,/dev:
Эти файловые системы являются виртуальными FS, т. е. находятся в памяти, а не на диске
Если вы планируете полагаться на
/proc, используйте/proc/1/, т.е. полагайтесь на что-то под PID 1, а не на какие-либо более поздние PID, чтобы обеспечить надежность/непротиворечивость, поскольку более поздние PID (процессы )не гарантируют существование.
Глядя на lstat (2)справочную страницу, вы можете получить некоторое представление о случаях, которые могут привести к сбою с ошибками, отличными от ENOENT (файл не существует.)
Самый очевидный из них:
EACCES Search permission is denied for one of the directories in the path prefix of path.
Итак, вам нужен каталог, в котором вы не можете выполнять поиск.
Да, вы можете найти тот, который уже есть в вашей системе (возможно /var/lib/private, если он существует? )Но вы также можете создать его самостоятельно с эквивалентом:
$ mkdir myprivatedir
$ touch myprivatedir/myunreachablefile
$ chmod 0 myprivatedir
$ ls -l myprivatedir/myunreachablefile
Операция lstat (2 )завершится с ошибкой EACCES. (Удаление всех разрешений для каталога гарантирует это. Возможно, вам даже не нужно так много, и chmod -xудаления разрешений на выполнение будет достаточно, поскольку разрешения на выполнение в каталоге необходимы для доступа к файлам в нем.)
Есть еще один творческий способ сделать lstat (2 )неработоспособным, взглянув на его справочную страницу:
ENOTDIR A component of the path prefix of path is not a directory.
Таким образом, попытка доступа к такому файлу, как /etc/passwd/nonexistent, должна вызвать эту ошибку, которая опять же отличается от ENOENT («Нет такого файла или каталога» )и может соответствовать вашим потребностям.
Другой:
ENAMETOOLONG path is too long.
Но вам может понадобиться очень длинное имя для этого. (Я полагаю, что 4096 байт — это обычное ограничение, но ваша система/файловая система может иметь более длинное имя.)
Наконец, трудно сказать, будет ли какое-либо из них действительно полезным для вас. Вы говорите, что хотите что-то, что не запускает сценарий «файл не существует». Хотя обычно это означает ошибку ENOENT, на практике многие проверки более высокого уровня -просто интерпретируют любые ошибки из lstat (2 )как «не существует».Например, test -eили эквивалент [ -e...]из оболочки могут просто интерпретировать все вышеперечисленное как «не существует», тем более что у него нет хорошего способа вернуть другое сообщение об ошибке и не возвращать ошибку. будет означать, что файл существует, что, безусловно, не так.