Указанная цель не является каталогом linux
Обновлено: 06.07.2024
Этичный хакинг и тестирование на проникновение, информационная безопасность
На днях довелось очищать сервер Linux от трояна и майнера. Сервер безголовый (только с консолью, без веб панелей или графических интерфейсов), антивирусы и анализаторы вредоносного трафика не установлены. Тем не менее, даже в таких условиях используя стандартные средства Linux можно довольно эффективно искать и деактивировать вредоносное ПО.
Чтобы было интереснее, методы будут опробованы на настоящем вредоносном ПО. На момент написания все ссылки на вредоносное ПО рабочие — можете попробовать себя в анализе, сборе информации о серверах злоумышленника и прочем. Конечно, я исхожу из того, что у вас хватит ума не запускать скаченные файлы двойным кликом и смотреть, что будет дальше. При поиске и деактивации вредоносного ПО (загрузчик, майнер, троян) на рабочем сервере было не до документирования, поэтому последующие скриншоты сделаны в тестовой системе, которую я специально заразил вирусом.
Как найти вирус на сервере Linux
Вредоносные программы, вирусы, трояны, майнеры имеют определённую цель. Для этой цели им необходимо выполнять те или иные действия — именно по этой активности и можно их найти. Кроме того, поскольку программы находятся в системе «нелегально», то им необходимо, во-первых, сохраниться после перезапуска компьютера; во-вторых, запуститься после перезапуска системы. Эти действия также могут выдать их.
В качестве активности вредоносного ПО можно выделить:
- прослушивание портов или связь с удалёнными компьютерами (характерно для троянов)
- повышенное потребление ресурсов компьютера (характерно для майнеров, программ для рассылки спама, компьютеров подключённых к ботнету)
Для закрепления в системе программа может:
- копировать свои файлы и скачивать другое вредоносное ПО
- добавлять задачи Cron
- добавлять свои файлы в автозагрузку служб
- модифицировать файлы профиля, автоматически выполняемые при входе пользователя в систему
Признаки взлома сервера Linux
Нагрузка на центральный процессор
Инструментарий:
Начинаем с анализа использования ЦПУ:
Некий процесс dbused создаёт слишком сильную нагрузку на систему.
Попробуем развернуть дерево процессов (клавиша «c»):
Никакой дополнительной информации по процессу dbused. Попробуем что-то узнать о нём с помощью ps:
Тоже мало толку.
Можно попытаться закрыть процесс, но он вновь сам запустится.
Нагрузка на постоянное хранилище
Инструментарий:
Посмотрим информацию об использовании диска процессами:
Следующая команда с интервалами в 20 секунд показывает все процессы, которые выполняли чтение и запись с диска:
На самом деле, на заражённом сервере найти источник проблемы мне помогла именно предыдущая команда, она в качестве процесса, который делал множество операций чтения/записи показала следующее:
Видимо, из-за недостатка прав (сервер был заражён с правами веб-службы), что-то для вредоносного ПО работало во внештатном режиме.
Открытые порты
Инструментарий:
Чтобы посмотреть установленные соединения (например, троян или часть бота подключились к управляющему компьютеру), выполните следующую команду:
Вывод в моём случае:
Обратите внимание на dbused — он подключён к 194.5.249.24:8080 — это и есть управляющий сервер или, в данном случае, компьютер отвечающий за координацию майнеров (пул). В качестве противодействия, можно заблокировать доступ к 194.5.249.24 с помощью iptables.
Вирус может быть настроен на прослушивания (открытие) порта. Открытые порты можно посмотреть командой:
Анализ открытых файлов
Инструментарий:
Посмотрим, какие есть открытые файлы, связанные с dbused:
Информации достаточно много, например, показаны IP адреса и порты с которыми связывается программа.
Чтобы показать только файлы в привычном смысле, то используйте команду следующего вида:
Как можно увидеть, файл найден, но он уже удалён. Вас не должен смущать тот факт, что исполнимый файл одновременно запущен (и использует ресурсы системы), но при этом является удалённым. В Linux не запрещено удалять используемый файл, он остаётся в кэше памяти и по-настоящему удаляется только когда будут закрыты все программы, используемые данный файл, либо когда процесс завершит свою работу, если это исполнимый файл.
Можно сделать вывод: файл копируется при каждом запуске системы, запускается, а затем удаляется (например, чтобы избежать обнаружения антивирусами). После перезагрузки компьютера всё повторяется вновь.
На самом деле, полученная информация не является бесполезной. Кроме сделанных выводов, что имеется механизм воссоздания вредоносного файла, можно сделать что-нибудь в этом роде:
В результате будет создан файл заглушка, который невозможно удалить и переписать. При следующем запуске ОС это может помешать вирусу нормально скопировать и запустить свою копию.
Для просмотра вообще всех открытых (настоящих) файлов, можно использовать следующую команду:
Для просмотра открытых файлов в определённой директории:
Возможно, вы сумеете обнаружить аномалии в системе.
Как узнать, какой процесс создаёт файл
Инструментарий:
Создадим правило для отслеживания изменений файла /usr/bin/dbused
Перезагрузим компьютер и после появления файла проверим, кто его создал и запустил:
Запущенные службы
Инструментарий:
Просмотр активных служб, запущенных с помощью Systemctl:
К автозагрузке с помощью Systemctl мы ещё вернёмся чуть ниже.
Поиск следов закрепления вредоносного ПО
Поиск недавно созданных файлов
Инструментарий:
Поиск файлов в указанной папке, которые были изменены менее 1 дня назад:
Чтобы найти все файлы, которые были изменены ровно 50 дней назад:
Чтобы найти все файлы, к которым был получен доступ ровно 50 дней назад:
Чтобы найти все файлы, которые были модифицированы более 50 дней назад и менее 100 дней назад:
Чтобы найти файлы, свойства которых (права доступа, владелец, группа) были изменены за последний час:
Чтобы найти файлы, которые были модифицированы за последний час:
Чтобы найти все файлы, доступ к которым был сделан за последний час:
Поиск служб в автозагрузке
Инструментарий:
Если вы хотите посмотреть только юниты, добавленные в автозагрузку, то используйте следующую конструкцию:
Посмотрите на две службы с именами:
На самом деле, вредоносное ПО может модифицировать файлы Systemctl и заменить собой любую службу или выбрать менее вызывающее название, но в данном случае очевидно, что это посторонние сервисы.
Можно посмотреть, что там внутри:
Говорит нам о том, что файл вируса спрятан в /bin/sysdr.
Поиск в директориях /etc/systemd/system/ и /usr/lib/systemd/system/ файлов созданных за последний день:
Знакомые нам файлы:
- /etc/systemd/system/pwnrige.service
- /usr/lib/systemd/system/pwnrigl.service
Поиск по содержимому файлов (по тексту)
Инструментарий:
Поиск строк sysdr или cp в директориях /etc/systemd/system/ и /usr/lib/systemd/system/:
Расписания задач Cron
Инструментарий:
Следующие две команды покажут содержимое задач Cron для всех пользователей:
Более гибкий вариант, не рассчитывает на имена пользователей:
Обратите внимание, как прочно укоренился вирус в системе:
Этот набор команд, который должен выполняться с периодичность 1 раз в минуту, прописан в следующих файлах:
Автоматически выполняемые скрипты
Инструментарий:
В Linux имеются скрипты, которые выполняются автоматически при входе пользователя в систему.
Некоторые из этих скриптов общие для всех пользователей, некоторые — у каждого пользователя свои:
Если вы не знаете, что именно нужно искать, то используйте следующую команду, которая выведет содержимое для всех файлов всех пользователей:
Посмотрите какая неприятность — в файле /root/.bash_profile найдена следующая строка:
Анализ таймеров
Инструментарий:
Вывод списка всех активных таймеров:
Анализ логов
Эта статья не совсем про Indicator of Compromise (IOC) и анализ атак, ставших причиной компрометации системы, поэтому не будем на этом сейчас останавливаться. Тем не менее, вас может заинтересовать:
Деактивация вируса в Linux
Попробуем собрать всё воедино и убрать службы из автозагрузки, удалить все исполнимые файлы и файлы автозапуска, сразу после этого перезагружаем компьютер, чтобы процесс вируса (если он ещё активен), не успел создать всё это заново:
Вместо успешного завершения блока команд и перезагрузки компьютера мы получили ошибку «Операция не позволена» для ряда файлов.
Причина в том, что с помощью атрибута файла «i» файлы заблокированы от удаления даже с помощью sudo. Подробности смотрите в статье «Атрибуты файлов в Linux». Чтобы разблокировать файлы, нужно использовать команду вида:
Получаем новую последовательность команд для деактивации вируса:
Если процесс вируса ещё активен, то в дополнение к команда очистки, можно завершить процесс вредоносного ПО с помощью kill.
Инструментарий:
Как вы могли обратить внимание, среди нашего инструментария только обычные утилиты Linux. Конечно, имеются системы предотвращения вторжений, Indicator of Compromise (IOC) (индикаторы компрометации), антивирусы, анализаторы вредоносного трафика и другой вредоносной активности. Но такие программы не всегда установлены и, на самом деле, не всегда требуются чтобы найти и даже устранить причину проблемы.
Ещё вы могли обратить внимание на скрипт, который скачивается планировщиком задач Cron — это загрузчик (Downloader), написан на Bash. Даунлоадеры — это небольшие программы, которые обычно сами не делают каких-либо деструктивных действий, но при этом загружают в операционную систему вирусы, трояны и другие вредоносные программы. В данном случае загрузчик скачивает и запускает троян ботнета и майнер. Сам загрузчик пытается закрепиться в системе и, более того, пытается заразить другие машины — ищет имена пользователей и ключи для входа в другие системы. В общем, скрипт весьма любопытный — в следующей части мы изучим его. Изучение захваченных скриптов, файлов, команд полезно не только для саморазвития — они также могут дать подсказки, каким ещё образом вирус мог попытаться закрепиться в системе.
Копирование файлов по списку (Не работает в скрипте, отдельно все хорошо)
На самом деле это единственный раздел про unix на этом форумеМодератор: /dev/random
Копирование файлов по списку
| в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Обработка кавычек осуществляется раньше, чем подстановка переменных. Если в переменной есть кавычки, то при подстановке они будут просто символами. Т.о., команда foo='"a b" "c d"'; cp $foo попытается скопировать файлы "a , b" и "c в каталог d" .
Да, в названии есть кавычки ' ' , которые система воспринимает как границы обозначения переменных.
"/home/serg/del/CD-27/05 - Конец ''Охоты на воков'', или Охота с вертолетов.mp3" "/tmp/dvd/CD-27/05 - Конец ''Охоты на воков'', или Охота с вертолетов.mp3"
Пока ничего лучше, чем экранирования обратным слэшем \ спец символов не нашёл.
Заэкранировал обратным слэшем, помогло. В скрипте, как рекомедует баш, так же взял переменную в кавычки. В общем, всё работает.
Да, в названии есть кавычки ' ' , которые система воспринимает как границы обозначения переменных.Я не о том. Вы пытались экранировать пробелы обычными двойными кавычками ("), но внутри переменной они считаются просто символами, и ничего не экранируют. И в результате пробелы продолжают вам мешать.
Вы можете использовать в списке для разделения имён файлов что-то другое, вместо пробела. Что-то, что в именах файлов у вас отсутствует. Например, табуляцию. Читаете строку ( read -r line ), делите по табуляции на 2 переменные ( from="$"; to="$" ) и затем делаете cp "$from" "$to" (обратите внимание на кавычки). Да, и не забудьте убрать эти ваши лишние кавычки из самого списка.
Команда mv в Linux является встроенной командой, ее основная функция заключается в перемещении файлов и каталогов. Однако функция команды mv не ограничивается перемещением файлов, она также выполняет множество других задач. В Linux mv означает перемещение.
В этом руководстве мы покажем, как перемещать файлы и каталоги в ОС Linux с помощью команды mv.
Вам может быть интересно:
Вы так же можете прочитать о командах Linux >>>Здесь<<<
Как использовать команду mv в Linux
Команда mv используется для перемещения файлов и каталогов из одного места в другое. При перемещении команда mv удалит исходный файл или каталог. Но будет ждать, пока файлы/каталоги будут полностью перемещены. При перемещении файла в пункт назначения, если в пункте назначения уже есть файл с тем же именем, он будет перезаписан.
Вы также можете использовать команду mv для переименования имени файла и каталога. Если оба файла имеет одно имя и находятся в одной файловой системе, это приведет к их переименованию.
Основной синтаксис команды mv выглядит следующим образом.
- [Options] относится к различным параметрам команды mv, например -f.
- Source (Источник) это может быть один файл или каталог или несколько файлов или каталогов.
- Destination (Место назначения) можно указать один файл или каталог.
Например, если нам нужно переместить файл text1.txt в каталог /dir1 , команда будет такой.
- Если файл Source состоит из множества файлов или каталогов, Destination должен быть каталогом. Файлы или каталоги Source будут перемещены в этот каталог Destination .
- Если Source это один файл, а Destination это каталог, файл перемещается в каталог Destination .
- А если источником является один файл, а конечным файлом является имя файла, исходный файл переименовывается в имя файла назначения.
- Если Источником является каталог, как и местом назначения, но каталог назначения не существует. В этом случае Исходный каталог будет переименован в каталог назначения. Если каталог назначения уже существует, исходный каталог перемещается в него.
Как переместить несколько файлов или каталогов командой mv
Чтобы переместить несколько файлов или каталогов, необходимо сначала указать имена файлов Source и каталог Destination .
Например, чтобы переместить файлы text1, text2 и text3 в каталог dir1, используйте следующую команду.
Команда mv также поддерживает сопоставление шаблонов, например, вы можете использовать такую команду для перемещения всех текстовых файлов в каталог
Как переименовать файл или каталог командой mv
Вы можете использовать команду mv для переименования файла или каталога.
Например, чтобы переименовать файл из text1.txt в text2.txt, используйте следующий синтаксис.
Например, если нам нужно переместить каталог dir1 в каталог dir2, синтаксис будет следующим.
Внимание: если каталога dir2 не существует, каталог dir1 переименовывается в dir2.
Параметры (опции) команды mv в Linux
Команда mv предоставляет различные опции для конкретных целей. Некоторые из полезных параметров команды mv являются:
Запрос перед перезаписью
Если файл Destination или каталог уже существуют, по умолчанию они перезаписываются. Параметр -i можно использовать для отображения запроса на подтверждение. Следующая команда используется для отображения подсказок перед перезаписью.
Если вы хотите перезаписать тип y или Y .
Не перезаписывать существующие файлы
Чтобы никогда не перезаписывать существующий файл, используйте опцию -n вместе с командой mv, как показано ниже.
При попытке переместить file1 в каталог dir1, если file1 уже существует, команда ничего не сделает; в противном случае файл будет перемещен в каталог dir1.
Принудительная перезапись
Файлы резервных копий
Чтобы создать резервную копию файла, используйте параметр командной строки -b. Для резервного копирования файла можно использовать следующий вариант команды.
В файле резервной копии появится тильда (
) с тем же именем, что и у оригинала.
Заключение
В этой статье мы показали, как использовать команду mv в Linux. Для получения дополнительной информации обратитесь к справке man mv.
Каждый пользователь, рано или поздно сталкивается с определенными проблемами в своей операционной системе Linux. Это может быть просто неправильное использование команд или их непонимание, так и такие серьезные ошибки Linux, как отсутствие драйверов, неработоспособность сервисов зависание системы и так далее. Linux очень сильно отличается от WIndows, это заметно также при возникновении проблем Linux. Вот допустим, произошла ошибка в программе Windows, она полностью закрывается или выдает непонятное число с кодом ошибки и все, вы можете только догадываться или использовать поиск Google, чтобы понять что произошло. Но в Linux все совсем по-другому.
Более того, если программу запускать из терминала, то все ошибки linux и предупреждения мы увидим прямо в окне терминала. и сразу можно понять что нужно делать.
Монтирование NTFS раздела от Windows 10 в Linux
Ошибка:
Решение:
sudo mount -t ntfs-3g -o remove_hiberfile /dev/sda2 /mnt
Ошибка:
Решение:
sudo ntfsfix /dev/sda3
Отключение режима гибернации в винде
Нет места, но место есть.
Проблема: ПО пишет, что закончилось место на диске, при этом df -h показывает, что место все-таки есть.
Решение: Надо проверить свободный айноды. df -hTi. Возможно их забили мелкие файлы.
Команда смены владельца и группы владельцев для директории и всех поддиректорий с файлами
sudo chown -R user:group /home/user/dir/
FTP сервер на Ubuntu server
Установить
sudo apt-get install vsftpd
Правим конфигурацию
sudo nano /etc/vsftpd.conf
Если надо анонимный доступ
anonymous_enable=Yes
чтение и правка файлов
local_enable=YES
write_enable=YES
папка входа по умоланию
local_root=/var/www
рестарт
sudo service vsftpd restart
Если права на файлы раздаются не верно
Раскомментируем строчку
umask 002
Расширить диск виртуальной машины KVM и VirtualBox
1)KVM
sudo qemu-img resize /home/vm/disk.img +10G
на вируалке
sudo apt-get install gparted
sudo swapoff /dev/vda5
sudo -X gparted
авторизация SSH без пароля
на своей машине
ssh-keygen -t rsa
в папке /home/имя пользователя/.ssh/id_rsa и id_rsa.pub появятся ключи
копируем на сервер
на сервере
chmod 600
Firefox средняя кнопка мыши не работает как прокрутка
Проброс портов iptables
Примонтировать флешку Ubuntu Linux
service srv1cv83 stop
sudo dpkg -l | more | grep 1c
sudo dpkg -r 1c-enterprise83-ws
sudo dpkg -r 1c-enterprise83-server
sudo dpkg -r 1c-enterprise83-common
dpkg -i 1c-enterprise83-common_8.3.6-2390_amd64.deb
dpkg -i 1c-enterprise83-server_8.3.6-2390_amd64.deb
dpkg -i 1c-enterprise83-ws_8.3.6-2390_amd64.deb
Google Chrome не предлагает сохранить пароли
Если Google Chrome не предлагает сохранить пароли и не использует автозаполнение, то причина может быть в том, что эти опции отключены в настройках. Для их включения перейдите во вкладку chrome://settings/, либо в меню выберите пункт «Настройки»:
На открывшейся странице в разделе «Автозаполнение» выберите пункт «Пароли»:
В открывшемся окне включите две опции:
- Предлагать сохранение паролей
- Автоматический вход (Автоматически входить на сайты с помощью сохраненного имени пользователя и пароля. Когда функция отключена, эти данные нужно вводить при каждом входе)
После этого автоматический вход и сохранение пароли должны начать работать.
Google Chrome не сохраняет пароли, хотя предлагает их сохранить
Эта ситуация более нестандартная, она может встречаться на различных операционных системах: в моём случае это Chromium на Linux, но сообщали также об аналогичной проблеме для Google Chrome на MacOS.
- После входа на веб-сайт, браузер, как обычно, предлагает сохранить пароль
- Я нажимаю на кнопку «Сохранить»
- Chrome не показывает никакие ошибки
- Но пароль не сохраняется: а) он не вводится автоматически при следующем заходе на сайт; б) пароль не отображается во вкладке chrome://settings/passwords
1. Выйдите из Chrome
2. Перейдите в директорию, где Chrome хранит данные пользователя — внутри домашней папки, в директории, зависящей от операционной системы:
4. Удалите файлы Login Data, Login Data-journal и Login Data 2-journal.
5. Повторите для других профилей, если необходимо.
После этого у меняв вновь включилось сохранение паролей.
Обратите внимание, что если у вас включена автоматическая синхронизация, то вы не потеряете сохранённые ранее пароли.
Какие файлы можно удалить при нехватке места на диске Linux
1. Удаление временных файлов
Файлы в папке /tmp/ будут удалены в любом случае при следующей перезагрузки системы. То есть с одной стороны их можно удалить достаточно безболезненно:
НО: может быть нарушена работа программ, которые запущены в настоящее время и которые сохранили какие-то данные в папку /tmp/.
2. Удаление файлов кэширования
В директории /var/cache/ много поддиректорий, которые можно удалить практически безболезненно (данные утеряны не будут, а программы создадут новые файлы кэширования). Эта директория вызывает особый интерес, поскольку на которых системах кэши разрастаются на гигабайты и десятки гигабайт. Иногда поиск проблемной директории в /var/cache/ может окончательно решить ситуацию с нехваткой места на диске.
Для удаления кэша шрифтов:
Для удаления кэша установочных пакетов (на Debian, Linux Mint, Ubuntu, Kali Linux и их производных):
Для удаления кэша установочных пакетов (на Arch Linux, BlackArch и их производных):
Удаление кэша справочных страниц:
Вы можете продолжить поиск больших кэшей применимо к программному обеспечению, установленному на вашей системе. Например, это могут быть кэши веб-сервера, прокси-сервера и т. д.
3. Удаление логов (журналов)
В этой папке (/var/log/) можно удалить практически все файлы, но старайтесь сохранить структуру папок, поскольку некоторые приложения после удаления здесь папки не в состоянии создать её второй раз…
На веб-серверах могут разрастись слишком сильно журналы веб-сервера.
Для удаления логов Apache на Debian, Linux Mint, Ubuntu, Kali Linux и их производных:
Для удаления логов Apache на Arch Linux, BlackArch и их производных:
Чтобы сервер начал создавать новые файлы журналов и записывать в них, нужно перезапустить службу веб-сервера.
В зависимости от интенсивности использования системы, накопленные журналы могут занимать гигабайты. В зависимости от системы файлы могут называться по-разному, более точный анализ рекомендуется выполнять с помощью утилиты ncdu:
4. Очистите корзину
Этот совет больше для настольных систем. Файлы, которые вы удалили в графическом интерфейсе рабочего стола, попадают в папку
/.local/share/Trash/files/, вы можете проанализировать их и при желании удалить (второй раз):
5. Удаление ненужных файлов исходного кода заголовков ядра
6. Удаление осиротевших пакетов
На Debian, Linux Mint, Ubuntu, Kali Linux и их производных удалить ненужные пакеты можно следующим образом:
7. Очистка журналов systemd
Со временем, в некоторых системах логи системы начинают занимать гигабайты на жёстком диске. Просмотреть журналы и освободить место вы можете с помощью команды journalctl
Чтобы увидеть, сколько место занимают журналы, выполните:
Чтобы удалить все записи, оставив только записей на 100 мегабайт, выполните:
Либо для удаления всех записей в системном журнале, старше одной недели:
8. Проанализируйте файлы Docker
Самой большой папкой является /var/lib/docker/overlay2/. Для анализа занимаемого места на диске выполните:
Я читал в учебниках, что Unix / Linux не разрешает жесткие ссылки на каталоги, но разрешает мягкие ссылки. Это потому, что когда у нас есть циклы и если мы создаем жесткие ссылки и через некоторое время удаляем исходный файл, он будет указывать на какое-то мусорное значение?
Если циклы были единственной причиной запрета жестких ссылок, то почему разрешены мягкие ссылки на каталоги?
Где следует .. указать? Особенно после удаления жесткой ссылки на этот каталог, в каталог, на который указывает .. ? Это должно указать куда-то. .. не нужно физически существовать на любом диске. В любом случае, операционная система отслеживает текущий рабочий каталог, поэтому относительно просто хранить список инодов, связанных с каждым процессом cwd, и ссылаться на него, когда он видит использование .. . Конечно, это будет означать, что символические ссылки нужно создавать с учетом этого, но вы уже должны быть осторожны, чтобы не нарушать символические ссылки, и я не думаю, что дополнительное правило сделает их бесполезными.Это просто плохая идея, так как невозможно определить разницу между жесткой ссылкой и оригинальным именем.
Разрешение жестких ссылок на каталоги нарушило бы структуру ориентированного ациклического графа файловой системы, возможно, создавая петли каталогов и висячие поддеревья каталогов, что могло бы привести к fsck любым ошибкам обходчиков дерева файлов.
Во-первых, чтобы понять это, давайте поговорим об инодах. Данные в файловой системе хранятся в блоках на диске, и эти блоки собираются вместе с помощью inode. Вы можете думать об иноде как о файле. У inode нет имен файлов. Вот где приходят ссылки.
Ссылка - это просто указатель на индекс. Каталог - это индекс, который содержит ссылки. Каждое имя файла в каталоге - это просто ссылка на индекс. Открытие файла в Unix также создает ссылку, но это другой тип ссылки (это не именованная ссылка).
Жесткая ссылка - это просто дополнительная запись каталога, указывающая на этот индекс. Когда вы ls -l , число после разрешений является именованным количеством ссылок. Большинство обычных файлов будут иметь одну ссылку. Создание новой жесткой ссылки на файл заставит оба имени файла указывать на один и тот же индекс. Примечание:
Теперь вы можете ясно видеть, что нет такой вещи, как жесткая ссылка. Жесткая ссылка такая же, как и обычное имя. В приведенном выше примере, test или test2 , что является исходным файлом, а какая жесткая ссылка? В конце концов, вы не можете сказать (даже по меткам времени), потому что оба имени указывают на одно и то же содержимое, один и тот же индекс:
-i Флаг ls показывает иноды номера в начале строки. Обратите внимание, что test и test2 есть один и тот же номер инода, но test3 другой.
Теперь, если вам разрешено делать это для каталогов, два разных каталога в разных точках файловой системы могут указывать на одно и то же. Фактически, subdir может указывать на своего деда, создавая цикл.
Почему этот цикл вызывает беспокойство? Потому что когда вы пересекаете, нет никакого способа обнаружить, что вы зацикливаетесь (без отслеживания номеров инодов во время прохождения). Представьте, что вы пишете du команду, которую необходимо выполнить через подпапки, чтобы узнать об использовании диска. Как бы du знать, когда он попадет в петлю? Это подвержено ошибкам и много бухгалтерии, du что нужно сделать, просто чтобы выполнить эту простую задачу.
Симлинки - это совершенно другой зверь в том смысле, что они представляют собой особый тип «файла», за которым обычно следуют многие API файловой системы. Обратите внимание, что символическая ссылка может указывать на несуществующий пункт назначения, потому что они указывают по имени, а не напрямую на индекс. Эта концепция не имеет смысла для жестких ссылок, потому что само существование «жесткой ссылки» означает, что файл существует.
Allowing hard links to directories would break the directed acyclic graph structure of the filesystem , Можете ли вы объяснить больше о проблеме с циклами, используя жесткие ссылки? Почему это нормально с символическими Похоже, что они разрешили это на Mac, добавив обнаружение цикла к системному вызову link () и отказавшись разрешить вам создавать жесткую ссылку на каталог, если это создаст цикл. Кажется, разумное решение. @psusi mkdir -pa / b; ночеклн ча; мв ц / б; - нет теоретического, что он не проверяет наличие аргументов каталога и просто переходит к ссылке, и поскольку цикл не выполнен, мы все хороши в создании 'c'. затем мы перемещаем 'c' в 'a / b', и цикл создается из a / b / c -> a / - проверка в link () недостаточно хороша Циклы очень плохие. Windows имеет эту проблему с "соединениями", которые являются жесткими ссылочными каталогами. Если вы случайно применили разрешения ко всему своему профилю, он обнаружит серию соединений, которые создают бесконечный цикл. Повторение через каталоги происходит до тех пор, пока ограничения длины пути не остановят его.За исключением точек монтирования, каждый каталог имеет один и только родитель: .. .
Один из способов pwd - проверить устройство: inode для «.» а также '..'. Если они совпадают, вы достигли корня файловой системы. В противном случае, найдите имя текущего каталога в родительском, поместите его в стек и начните сравнивать '../.' с '../ ..', затем '../../.' с '../../ ..' и т. д. Как только вы дойдете до корня, начните выталкивать и печатать имена из стека. Этот алгоритм основан на том факте, что каждый каталог имеет одного и только одного родителя.
Если разрешены жесткие ссылки на каталоги, на кого должен .. указывать один из нескольких родителей ? Это одна из веских причин, по которым жесткие ссылки на каталоги запрещены.
Символьные ссылки на каталоги не вызывают этой проблемы. Если программа хочет, она может выполнить lstat() каждую часть имени пути и обнаружить, когда встречается символическая ссылка. pwd Алгоритм возвращает истинный абсолютный путь к файлу для целевого каталога. Тот факт, что где-то есть фрагмент текста (символическая ссылка), указывающий на целевой каталог, в значительной степени не имеет значения. Существование такой символической ссылки не создает петлю в графе.
Не уверен в этом. Если мы считаем, .. что это своего рода виртуальная жесткая ссылка на родителя, то нет технической причины, по которой у цели ссылки может быть только одна другая ссылка. pwd просто придется использовать другой алгоритм для разрешения пути.Вы можете использовать bind mount для симуляции жестких ссылок на каталоги
Я хотел бы добавить еще несколько моментов по этому вопросу. Жесткие ссылки на каталоги разрешены в Linux, но ограниченным способом.
Один из способов проверить это, когда мы перечисляем содержимое каталога, мы находим два специальных каталога "." а также "..". Как мы знаем "." указывает на тот же каталог, а ".." указывает на родительский каталог.
Итак, давайте создадим дерево каталогов, где «a» является родительским каталогом, у которого каталог «b» является дочерним.
Запишите индекс каталога "а". И когда мы делаем ls -la из каталога «а», мы можем видеть, что «.» каталог также указывает на тот же индекс.
И здесь мы можем обнаружить, что каталог «а» имеет три жестких ссылки. Это связано с тем, что индекс 797358 имеет три жесткие ссылки на имя "." внутри каталога "a" и имя как ".." внутри каталога "b" и один с именем "a" itslef.
Таким образом, здесь мы можем понять, что жесткие ссылки существуют только для каталогов, связанных с их родительскими и дочерними каталогами. Таким образом, каталог без дочерних элементов будет иметь только две жесткие ссылки, и поэтому каталог «b» будет иметь только две жесткие ссылки.
Одна из причин, по которой жесткое связывание каталогов свободно предотвращается, заключается в том, чтобы избегать бесконечных циклов ссылок, которые могут запутать программы, пересекающие файловую систему.
Поскольку файловая система организована как дерево и дерево не может иметь циклическую ссылку, этого следует избегать.
Хороший пример. Это очистило мои сомнения. Таким образом, эти случаи обрабатываются особым образом, чтобы избежать бесконечных циклов. правильно? Поскольку у нас есть ограниченный способ разрешения жестких ссылок для каталогов, то есть ".." и "." мы не достигнем бесконечного цикла, и поэтому нам не потребуются какие-либо особые способы избежать их, поскольку они не произойдут :)Ничто из перечисленного не является реальной причиной запрещения жестких ссылок на каталоги; каждую проблему довольно легко решить:
- циклы в древовидной структуре вызывают сложный обход
- несколько родителей, так что же является «настоящим»?
- сборка мусора в файловой системе
Реальная причина (как намекают @ Турбьёрна Равн Andersen) приходит , когда вы удалите каталог , который имеет несколько родителей, из каталога , на который указывает .. :
На что .. сейчас следует указывать?
Если каталог удален из его родителя, но количество ссылок по-прежнему больше, чем 0 тогда, должно быть что-то, где-то еще указывающее на него. Вы не можете оставить .. указывать ни на что; на многие программы полагается .. , поэтому системе придется обходить всю файловую систему, пока она не найдет первое, что указывает на удаленный каталог, просто для обновления .. . Либо так, либо файловая система должна была бы поддерживать список всех каталогов, указывающих на жестко связанный каталог.
В любом случае, это может привести к снижению производительности и дополнительным осложнениям для метаданных файловой системы и / или кода, поэтому разработчики решили не допустить этого.
Это также легко решить: ведите список родителей дочернего каталога, который вы обновляете при добавлении или удалении ссылки на дочерний каталог. Когда вы удаляете канонического родителя (цель ребенка .. ), обновитесь, .. чтобы указать на одного из других родителей в списке. Я согласен. Не ракетостроение, чтобы решить. Но, тем не менее, это приводит к снижению производительности, и это заняло бы немного больше места в метаданных файловой системы и добавило бы сложности. И поэтому дизайнеры пошли на простой, быстрый подход - не разрешать ссылки на жесткие каталоги. Ссылки Sym на dirs "нарушают устоявшуюся семантику и поведение", но все же они разрешены. Таким образом, некоторые команды нуждаются в параметрах для контроля за тем, идут ли ссылки sym (например, -L в find и cp). Когда программа следует за «..», возникает дальнейшая путаница, отсюда и разница в выводе из pwd и / bin / pwd после обхода ссылки sym. Там нет "Unix ответы"; просто дизайнерские решения. Этот вращается вокруг того, что становится "..", как я сказал в своем ответе. К сожалению, «..» даже не упоминается в ответе, за который все остальные так смущенно голосуют. Кстати, я не говорю, что я за жесткие ссылки на dirs. Не за что. Я не хочу, чтобы моя дневная работа была тяжелее, чем сейчас. Это не то, что говорит POSIX, но IMO '..' никогда не должно было быть концепцией файловой системы, а должно быть синтаксически разрешено в путях, так что a/.. это всегда будет означать . . Вот как работают URL, кстати. Это браузер, который разрешает «..» еще до того, как он попадает на сервер. И это прекрасно работает.Создание жесткой ссылки на каталоги было бы необратимым. Предположим, у нас есть:
Я жестко связываю это с /dir2 .
Так что /dir2 теперь также содержит все эти файлы и каталоги
Что если я передумаю? Я не могу просто rmdir /dir2 (потому что это не пусто)
И если я рекурсивно удаляю в /dir2 . он тоже будет удален /dir1 !
ИМХО, это в значительной степени достаточная причина, чтобы избежать этого!
Редактировать :
Комментарии предлагают удалить каталог, сделав rm на нем. Но rm в непустом каталоге происходит сбой, и это поведение должно сохраняться независимо от того, является ли каталог жестким или нет. Так что вы не можете просто rm отключить его. Для этого потребуется новый аргумент rm , просто чтобы сказать: «если индекс узла имеет счетчик ссылок> 1, то только отсоединить каталог».
Что, в свою очередь, нарушает другой принцип наименьшего удивления: это означает, что удаление только что созданной жесткой ссылки на каталог не совпадает с удалением обычной жесткой ссылки на файл .
Я перефразирую свое предложение: без дальнейшей разработки создание жесткой ссылки было бы необратимым (поскольку никакая текущая команда не может обработать удаление, не будучи несовместимым с текущим поведением)
Если мы позволим доработать кейс для разработки, количество подводных камней и риск потери данных, если вы недостаточно осведомлены о том, как работает система, такое развитие событий подразумевает ИМХО достаточную причину для ограничения жестких ссылок на каталоги.
Это не должно быть проблемой. В вашем случае, когда мы создаем hardlink для dir2, мы должны сделать hardlink для всего содержимого в dir1, и поэтому, если мы переименуем или удалим dir2, будет удалена только дополнительная ссылка на inode. И это не должно влиять на dir1 и его содержимое, так как существует хотя бы одна ссылка (dir1) на inode. Ваш аргумент неверен. Вы бы просто отсоединили его, а не делали rm -rf. И если количество ссылок достигнет 0, то система будет знать, что она может также удалить все содержимое. Вы не можете просто отсоединить его, как обычный файл, потому что rm в каталоге не отсоединяйте его, если он не пустой. Смотрите Редактировать.Это хорошее объяснение. Относительно "Кто из нескольких родителей должен .. указать на?" Одним из решений было бы для процесса поддерживать свой полный путь wd, либо в виде inode, либо в виде строки. Иноды будут более надежными, так как имена могут быть изменены. По крайней мере, в прежние времена для каждого открытого файла существовал внутренний индекс, который увеличивался при каждом открытии файла, уменьшался при закрытии. Когда он достигнет нуля, хранилище, на которое он указывал, будет освобождено. Когда файл больше не был открыт никому, он (копия в ядре) был бы заброшен. Это позволило бы сохранить путь действительным, если какой-либо другой процесс переместил каталог в другой каталог, в то время как подкаталог находился в пути другого процесса. Подобно тому, как вы можете удалить открытый файл, но он просто удаляется из каталога,
Жесткие ссылки на каталоги раньше свободно разрешались в Bell Labs UNIX, по крайней мере, V6 и V7. Не знаю о Беркли или более поздних версиях. Флаг не требуется. Не могли бы вы сделать петли? Да, не делай этого. Это очень ясно, что вы делаете, если вы делаете петлю. Если вы будете практиковать завязывание узлов вокруг шеи, пока вы ждете своей очереди, чтобы выпрыгнуть из самолета, если у вас другой конец удобно подвешен на крюке на насадке.
То, что я надеялся сделать с этим сегодня, это жестко связать lhome с home, чтобы я мог иметь доступ к / home / admin независимо от того, был ли / home скрыт с помощью автомаута над home, причем этот автомонтирование имеет символическую ссылку с именем admin на / lhome. / administ. Это позволяет мне иметь административную учетную запись, которая работает независимо от состояния моей основной домашней файловой системы. Это IS эксперимент для Linux, но я думаю , что узнал в свое время на основе UCB в SunOS , что automounts делаются на уровне строки ASCII. Трудно понять, как их можно было бы сделать иначе, как слой поверх любой произвольной ФС.
Я читал в другом месте, что. и .. больше не являются файлами в каталоге. Я уверен, что для всего этого есть веские причины, и многое из того, что нам нравится (например, возможность монтировать NTFS), возможно благодаря таким вещам, но некоторая элегантность UNIX была в реализации. Именно такие преимущества, как универсальность и гибкость, обеспеченные этой элегантностью, позволили ей быть настолько прочной и выдерживать в течение четырех десятилетий. По мере того, как мы теряем изящные реализации, в конечном итоге он становится похожим на Windows (надеюсь, я ошибаюсь!). Кто-то тогда создаст новую ОС, основанную на элегантных принципах. Что-то думать о. Возможно, я ошибаюсь, я (очевидно) не знаком с текущей реализацией. это является Удивительно, насколько 30-летнее понимание применимо к Linux . большую часть времени!
Я думаю, хотя я могу ошибаться, . и .. это не жесткие ссылки в файловой системе для современных файловых систем. Однако драйвер файловой системы подделывает их. Именно эти файловые системы останавливают жесткие ссылки на каталоги. Для старых файловых систем это было возможно (но опасно). Чтобы сделать то, что вы пытаетесь, посмотрите mount --bind , посмотрите также mount --make… и, возможно, контейнеры.Исходя из того, что я понял, основная причина заключается в том, что полезно иметь возможность изменять имена каталогов, не портя запущенные программы, которые используют свой рабочий каталог для ссылки на другие файлы. Предположим, вы использовали Wine для запуска
/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe и
/.wine вместо него хотите переместить весь префикс . Если по какой-то странной причине Firefox drive_c/windows обращался к нему ../../windows , ссылаясь на него , переименование
/.newwineprefix прерывает реализации, .. которые отслеживают родительский каталог как текстовую строку вместо inode.
Хранить inode одного родительского каталога должно быть проще, чем пытаться отслеживать каждый путь как текстовую строку, так и серию inode.
Другая причина в том, что неправильно работающие приложения могут создавать циклы. Приложения, работающие с приложениями, должны иметь возможность проверять, является ли индекс перемещаемого каталога тем же, что и индекс любого из вложенных каталогов, в которые он перемещается, точно так же, как вы не можете переместить каталог в себя, но это не может быть применено принудительно. на уровне файловой системы.
Еще одна причина может заключаться в том, что если бы вы могли создавать жесткие ссылки на каталоги, вы бы хотели запретить жесткую ссылку на каталог, который вы не можете изменить. find имеет соображения безопасности, потому что он используется для очистки файлов, созданных другими пользователями, из временных каталогов, что может вызвать проблемы, если пользователь переключает реальный каталог для символической ссылки во время find вызова другой команды. Возможность жесткого связывания важных каталогов вынудит администратора добавить дополнительные тесты, find чтобы избежать их влияния. (Хорошо, вы уже не можете сделать это для файлов, поэтому эта причина недействительна.)
Еще одна причина заключается в том, что хранение inode родительского каталога может обеспечить дополнительную избыточность в случае повреждения или повреждения файловой системы. Если вы хотите .. перечислить все родительские каталоги, которые жестко связаны с этим, так что другой, произвольный родительский элемент может быть легко найден, если текущий разделен, не только вы нарушаете идею о том, что жесткие ссылки равны, вы должны изменить способ Файловая система хранит и использует inode. Если бы программы обрабатывали пути как серию (уникальную для каждой жесткой ссылки) инодов каталогов, этого можно было бы избежать, но вы не получите избыточности в случае повреждения файловой системы.
Читайте также: