Почему "ls -a" скрывает какой-либо существующий каталог от пользователя root?

Question

Сегодня я нашел кое-что действительно интересное (по крайней мере для меня) на одном из наших тестовых серверов:

Я могу перейти в существующий каталог из моего фактического рабочего каталога, используя относительный путь, но этот же каталог не отображается при использовании ls -a .

Вот сессия оболочки (как root):

$ pwd
/you/are/here
$ ls -a
. ..                       <-- Note: "somedir" is not shown to root
$ echo $CDPATH

$ cd somedir               <-- But still: "cd" works fine
$ pwd
/you/are/here/somedir
$ cd ..
$ pwd
/you/are/here
$ ls -a
. ..

Может кто-нибудь сказать мне, как это вообще возможно? Я проверил: ls это из /bin/ls , а pwd это /bin/pwd , оба из их оригинального пакета (я имею в виду: не взломан).

/you - смонтированный EMC-диск (ext3). И существует somedir как я могу перечислить его содержимое (есть несколько подкаталогов, файлов). Его имя не начинается с точки.

Еще один сеанс оболочки, с дополнительной информацией о командах и выводе ls :

root@U-TEST@AT$/bin/ls -ali
total 4
16515074 drwxrwxr-x  2 U8000966 test 2048 Sep  1 07:39 .
16515073 drwxrwxr-x  3 U8000966 test 2048 Apr 27  2006 ..
root@U-TEST@AT$ls -ali somewhere | head -5
total 182
16515075 drwxrwxr-x  43 U8000966 test  2048 Sep  1 07:39 .
16515074 drwxrwxr-x   2 U8000966 test  2048 Sep  1 07:39 ..
16519169 drwxrwxrwx   4 U8000966 test  2048 Jul 25  2007 AAA
16515124 drwxrwxr-x   3 U8000966 test  2048 May 12  2006 BBB
root@U-TEST@AT$type ls
ls is aliased to `/bin/ls $LS_OPTIONS'
root@U-TEST@AT$type pwd
pwd is a shell builtin
root@U-TEST@AT$/bin/pwd
/you/are/here
root@U-TEST@AT$cd somewhere
root@U-TEST@AT$/bin/pwd
/you/are/here/somewhere
root@U-TEST@AT$type cd
cd is a shell builtin

Обратите внимание на итоговые 4 после первого ls -ali . (Я не знаю, если это актуально ...)

Еще несколько тестов:

root@UR-TEST@AT$ls
.  ..
root@U-TEST@AT$touch somewhere/testfile
root@U-TEST@AT$ls
.  ..
root@U-TEST@AT$cp somewhere/testfile ./
root@U-TEST@AT$ls
.  ..  testfile
root@U-TEST@AT$du .
2       .
root@URBIS-TEST@AT$

И EMC: http://www.emc.com/products/family/disk-library-family.htm , но в данном случае они являются только поставщиками дисков, с жесткими дисками, отформатированными как ext3.

ОБНОВИТЬ

(Извините, но вчера мне пришлось уйти)

Я сделал проверить echo * и его . .. Вот LS_OPTIONS: -a -N --color=tty -T 0 .

Я проверил автомонтирование, упомянутое Жилем, но когда я перешел somewhere и выдал команду mount|grep somewhere там ничего не вышло.

Вот вывод lsattr и strace как было предложено: http://gist.github.com/566947

Answer 1

В то время, когда я пишу это, вы не исключили каких- либо эффектов в $LS_OPTIONS . В GNU ls есть несколько опций игнорирования файлов, а ls -I foo -a прежнему игнорирует foo . Но остальная часть моего ответа предполагает, что вы получите те же результаты без $LS_OPTIONS .

total 4 строки, на самом деле не удивительно. Это общее количество блоков, используемых . и .. Если . является пустым и .. небольшим и в файловой системе, размер блока которой равен блокам 4 ls (что обычно: GNU ls по умолчанию составляет блоки 1 КБ, а ext [234] часто использует блоки 4 КБ), тогда ожидаемая сумма равна 0 + 1 * 4 = 4.

В файловой системе, в которой находится /you/are/here , происходит нечто необычное, но не неслыханное. Когда вы запрашиваете содержимое /you/are/here (с помощью opendir() и readdir(3)), файловая система отвечает только с помощью . и .. ; тем не менее, когда вы предполагаете, что /you/are/here/somedir существует, вам говорят, что это так. Это удивительное, но возможное поведение.

Возможное, но крайне маловероятное объяснение - это демон (как в демоне Максвелла, а не как в программе- демоне ), который перемещает somedir на место, когда вы обращаетесь к нему, и убирает его с пути, когда вы перечисляете каталог. Таким образом, наблюдаемая вами особенность может быть вызвана обычной программой, которая просто делает правильные предположения, она не указывает на что-то не так с операционной системой.

На самом деле, операционная система, вероятно , ведет себя странным образом. Распространенным виновником является система автоматического монтажа. Система автомонтирования работает примерно так:

• Каталог, скажем /you/are/here , устанавливается в качестве места для точек монтирования. Там смонтирована специальная файловая система (возможно, называемая autofs).

• Когда вы пытаетесь получить доступ к записи в /you/are/here , скажем /you/are/here/somedir , драйвер файловой системы пытается смонтировать файловую систему somedir . Например, он может найти строку вроде somedir = /dev/foo или somedir = server:/loca/tion в своем файле конфигурации и смонтировать указанное устройство или расположение NFS как /you/are/here/somedir .

• Когда вы перечисляете каталог /you/are/here , вы видите подкаталог для каждой файловой системы, которая в настоящий момент смонтирована.

• Когда вы прекращаете использовать /you/are/here/somedir , возможно, после некоторой задержки, автомонтировщик somedir . Так что somedir больше не появляется в списке /you/are/here .

Answer 2

Что показывает "which ls" или "alias"? Возможно, ваша команда ls заменяется псевдонимом или чем-то подобным? Запуск следующего может исключить это:

/bin/ls -a /you/are/here

Немного предыстории:

Псевдоним имеет приоритет над /bin/ls , но which ls прежнему показывает /bin/ls . Вы можете воссоздать то, на что я ссылаюсь, так:

1. Создайте bash-скрипт с именем ls , содержащий:

   #!/bin/bash
   echo this is not ls
   

   • Создайте псевдоним сценария bash:

     псевдоним ls = '~/ls'

   • Теперь запустите ls . Вы должны получить "this is ls", но which ls показывает /bin/ls .

Также может быть полезно исключить autofs/automount.

После просмотра опубликованных обновлений ...

Возможно, LS_OPTIONS содержит --hide или --ignore?

~/dirtest$ ls -a
.  ..  somewhere
~/dirtest$ ls -a --ignore='some*'
.  ..

Что значит...

echo $LS_OPTIONS

...шоу? Может быть, даже попробовать ...

unset LS_OPTIONS

... затем снова запустите ls -a.

Возможно, что LS_OPTIONS устанавливается в вашем .bashrc или другом конфигурационном файле. (может быть, даже на глобальном уровне, из /etc /bash * (или любого другого файла конфигурации для рассматриваемой оболочки: .login, .profile и т. д.)

Answer 3

Жольт, пожалуйста, попробуйте эти три шага:

1. cd /
2. exec bash
3. /usr/bin/find /you/are/here -ls

Возможно, пришло время для fsck ... :-(

Но перед этим вы можете попробовать (после резервного копирования чего-либо внутри somedir):
cd /you/are/here && mkdir somedir .
cd /you/are/here && ln somedir newdir (от имени пользователя root).

Также проверьте mount | egrep -e 'somedir|you|are|here' для любых странностей.

Answer 4

Можете ли вы попробовать другие инструменты, которые могут пройти по дереву каталогов?

Например, du -h чтобы получить размер каталогов? Какое поведение вы наблюдаете, если вы запускаете его из корня диска или из /you/are/here по сравнению с /you/are/here/somedir?

Также - можете ли вы создать файл в /you/are/here/somedir? Если да, то сохраняется ли оно после того, как вы покидаете каталог? Делает ли создание файла каталог видимым для команды ls?

Answer 5

Следующее может или не может помочь, но я хотел бы видеть вывод следующих двух команд:

$ lsattr -av somedir
$ strace ls -a somedir

Answer 6

Возможно, какой-то процесс что-то делает с каталогом. Вы пробовали использовать lsof dirname , lsof /path/to/parent/* и lsof dirname/*?

А как насчет stat dirname?

Что насчет readlink -ev dirname?

Я вижу, вы type ls - что показывает type -a ls ?

Есть ли в $PATH что-нибудь необычное? Включается ли . (Точка)?

Какую оболочку вы используете? Вы пытались сделать свое первоначальное имя ls dirname в другой оболочке (особенно после совершенно новой сессии / входа в систему?

Если вы используете оболочку с завершением табуляции, будет ли она завершена для имени каталога?

У вас есть доступ к файловому менеджеру с графическим интерфейсом или в текстовом режиме, например, mc (Midnight Commander) или emacs dired? Могут ли они входить и выходить из этого каталога?

Я серьезно подозреваю, что что-то повреждено или взломано.

Answer 7

Помощь LS предоставляет это, что может быть полезным.

-a, --all                  do not ignore entries starting with .
-A, --almost-all           do not list implied . and ..
    --author               with -l, print the author of each file

Answer 8

На данный момент, мне кажется, наиболее вероятным является то, что ваш сервер был взломан и был загружен руткит, который не дает каталогу отображаться в списках. Корневой комплект будет делать это с модулем ядра, который перехватывает или перенаправляет системные вызовы readdir и getdents. Если модуль остается резидентным, он, вероятно, также скрывается от появления в /proc /modules или lsmod.