Посмотреть кто занял файл linux
Обновлено: 07.07.2024
Есть ли способ в Unix узнать, кто получил доступ к определенному файлу за последнюю 1 неделю? Это может быть пользовательский или какой-то скрипт, который может переместиться в другое место. Могу ли я получить список имен пользователей, которые обращались к определенному файлу? Как я могу узнать, кто обращается к конкретному файлу ??
Дата, когда файл был прочитан в последний раз, называется временем доступа, или для краткости atime . Все файловые системы Unix могут хранить его, но многие системы не записывают его, потому что он имеет (как правило, небольшое) снижение производительности. ls -ltu /path/to/file или stat /path/to/file показывает время доступа к файлу.
Если пользователь получил доступ к файлу и не пытался скрыть свои треки, его история оболочки (например
/.bash_history ) может иметь подсказки.
Чтобы узнать, что или у кого есть файл, открытый сейчас, используйте lsof /path/to/file .
Чтобы записать, что произойдет с файлом в будущем, есть несколько способов:
Используйте inotifywait . inotifywait -e access /path/to напечатает строку, /path/to/ ACCESS file когда кто-то читает file . Этот интерфейс не скажет вам, кто получил доступ к файлу; Вы можете позвонить, lsof /path/to/file как только появится эта линия, но есть условие гонки (доступ может быть прекращен к тому времени, когда lsof начнет работу).
LoggedFS - это наращиваемая файловая система, которая обеспечивает представление дерева файловой системы и может выполнять более сложные записи всех обращений через это представление. Чтобы настроить его, см. Синтаксис файла конфигурации LoggedFS .
Вы можете использовать подсистему аудита Linux для регистрации большого количества вещей, включая доступ к файловой системе. Убедитесь, что auditd демон запущен, затем настройте то, с чем вы хотите войти auditctl . Каждая регистрируемая операция записывается в /var/log/audit/audit.log (в типичных распределениях). Чтобы начать просмотр определенного файла:
Если вы помещаете наблюдение в каталог, рекурсивно также просматриваются файлы в нем и его подкаталогах.
В Linux такой идентификатор называется PID, и узнать его можно несколькими способами. В этой статье мы рассмотрим, как узнать PID процесса в Linux, а также зачем это может вам понадобиться.
Как узнать pid процесса Linux
Самый распространённый способ узнать PID Linux - использовать утилиту ps:
ps aux | grep имя_процесса
Кроме нужного нам процесса, утилита также выведет PID для grep, ведь процесс был запущен во время поиска. Чтобы его убрать, добавляем такой фильтр:
ps aux | grep имя_процесса | grep -v grep
Например, узнаём PID всех процессов, имя которых содержит слово "Apache":
ps aux | grep apache | grep -v grep
2. pgrep
Если вам не нужно видеть подробную информацию о процессе, а достаточно только PID, то можно использовать утилиту pgrep:
По умолчанию утилита ищет по командной строке запуска процесса, если нужно искать только по имени процесса, то надо указать опцию -f:
3. pidof
Эта утилита ищет PID конкретного процесса по его имени. Никаких вхождений, имя процесса должно только совпадать с искомым:
С помощью опции -s можно попросить утилиту выводить только один PID:
pidof -s apache2
4. pstree
Утилита pstree позволяет посмотреть список дочерних процессов для определённого процесса, также их pid-идентификаторы. Например, посмотрим дерево процессов Apache:
pstree -p | grep apache2
Как узнать PID скрипта
Когда вы запускаете скрипт в оболочке, например Bash запускается процесс известный как подоболочка и выполняет последовательно все команды скрипта. Чтобы узнать PID процесса подоболочки Bash, запущенной для скрипта, обратитесь к специальной переменной $$. Эта переменная доступна только для чтения, поэтому вы не сможете ее редактировать:
Каким процессом занят файл Linux
Выше мы рассмотрели, как получить PID процесса Linux по имени, а теперь давайте узнаем PID по файлу, который использует процесс. Например, мы хотим удалить какой-либо файл, а система нам сообщает, что он используется другим процессом.
С помощью утилиты lsof можно посмотреть, какие процессы используют директорию или файл в данный момент. Например, откроем аудио-файл в плеере totem, а затем посмотрим, какой процесс использует её файл:
В начале строки мы видим название программы, а дальше идёт её PID. Есть ещё одна утилита, которая позволяет выполнить подобную задачу - это fuser:
Здесь будет выведен только файл и PID процесса. После PID идёт одна буква, которая указывает, что делает этот процесс с файлом или папкой:
- c - текущая директория;
- r - корневая директория;
- f - файл открыт для чтения или записи;
- e - файл выполняется как программа;
- m - файл подключен в качестве библиотеки.
Кто использовал файл в Linux
Узнать процесс, который сейчас занимает файл, достаточно просто. Но как узнать, какой процесс обращается к файлу не надолго, например, выполняет его как программу или читает оттуда данные? Эта задача уже труднее, но вполне решаема с помощью подсистемы ядра auditd. В CentOS набор программ для работы с этой подсистемой поставляется по умолчанию, в Ubuntu же его придётся установить командой:
sudo apt install auditd
Теперь создаём правило для мониторинга. Например, отследим, кто запускает утилиту who:
auditctl -w /usr/bin/who -p x -k who_exec
Здесь -w - адрес файла, который мы будем отслеживать, -p - действие, которое нужно отслеживать, -k - произвольное имя для правила. В качестве действия могут использоваться такие варианты:
Теперь выполним один раз who и посмотрим, что происходит в логе с помощью команды ausearch:
sudo ausearch -i -k who_exec
Здесь в секции SYSCALL есть PID процесса, под которым была запущена программа, а также PPID - программа, которая запустила нашу who. Копируем этот PID и смотрим информацию о нём с помощью ps:
ps aux | grep 15595
Становиться понятно, что это bash.
Какой процесс использует порт в Linux
Иногда необходимо узнать PID Linux-программы, которая использует сетевой порт, например 80. Для этого можно использовать утилиту ss:
sudo ss -lptn 'sport = :80'
Мы видим, что это несколько процессов Apache. Использовав опцию dport, можно узнать, какой процесс отправляет данные на указанный порт:
sudo ss -lptn 'dport = :80'
Выводы
В этой статье мы рассмотрели, как узнать PID процесса в Linux по различным условиям: имени или файлу. Как видите, всё достаточно просто, и в считанные минуты можно можно понять, что происходит с вашей операционной системой, и какой процесс за это отвечает.
Нет похожих записей
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.
В случае с Linux проблема заключается в том, что иногда программы сообщают нам слишком много сведений о своей работе. Как найти в этом море информации именно то, что нужно? Когда киношный хакер сидит перед терминалом и смотрит на текст, прокручивающийся со скоростью 500 строк в секунду, выглядит это впечатляюще. Но в реальной жизни почти бесполезно изучать логи, выводимые на экран с такой скоростью. Хотя, если попрактиковаться, из этого потока информации можно иногда, рискуя ошибиться, выхватить какое-нибудь ключевое слово. Но задачу анализа логов в реальном времени это не решает.
Как и во многих других случаях, в Unix-подобных системах есть инструменты для решения вышеописанной задачи. И, что неудивительно, таких инструментов существует довольно много. Если вы, например, пользовались командой tail , то вы уже видели один из таких инструментов. Но tail — это лишь вершина айсберга.
Давайте рассмотрим пример анализа файла, который можно назвать «матерью всех логов». Это — /var/log/syslog . Попробуйте вывести его на экран с помощью команды cat или less (я, в своих системах, всегда создаю псевдоним more для команды less , поэтому если я вдруг упомяну команду more — знайте, что я имею в виду less ). Этот файл, вероятнее всего, будет очень большим, его размеры будут постоянно расти. В обычной настольной системе он ведёт себя довольно спокойно, но в некоторых старых системах и на серверах в нём можно увидеть последствия бурной деятельности разных программ. В любом случае, за исключением тех ситуаций, когда система только что загружена, в нём будут многие страницы данных.
Хакерский подход к анализу логов
И эта проблема характерна далеко не только для файла syslog . Например, интересно может быть наблюдать за файлом листинга в ходе выполнения долгой компиляции кода. То же относится и к наблюдению за перестроением RAID-массива. В общем-то, в Linux всегда можно найти некий большой файл, постоянно пополняемый свежими сведениями, за которым нужно понаблюдать.
Команда tail
Традиционный подход к наблюдению за файлами, постоянно пополняемыми информацией, заключается в использовании команды tail . Она берёт большой файл и возвращает лишь некоторое количество его последних строк. Эту команду можно вызвать с опцией -f . Тогда она будет ждать появления в файле новых данных и выводить их. Эта опция весьма полезна для наблюдения за файлами, в которые постоянно добавляется что-то новое. Опция -F приводит к практически такому же эффекту, но благодаря ей tail , если не может сразу открыть файл, будет продолжать пытаться открыть его. С помощью опции -m можно задавать количество выводимых последних строк файла, а с помощью опции -c — количество байтов. Опция -s позволяет задавать частоту проверки изменений файла.
Как по мне, так всё это выглядит очень даже хорошо. Попробуйте такую команду:
Вы увидите несколько строк из конца файла системного журнала. А если подключить к компьютеру USB-устройство или отключить такое устройство от компьютера, можно увидеть, как сведения, попавшие в журнал, практически мгновенно выводятся на экране. Повторно запускать tail при этом не нужно.
Возможно, вы уже пользовались этим приёмом. Вышеописанная конструкция хорошо справляется со своей задачей, она известна и применяется довольно часто. Но есть и другие способы наблюдения за файлами, которыми вы, возможно, ещё не пользовались.
Меньше — значит больше: полезные возможности команды less
У команды less есть опция +F , которая превращает эту команду в хорошую замену команды tail . На самом деле, если вы испытаете команду, приведённую ниже, вас может посетить мысль о том, что результаты её работы не очень-то и отличаются от результатов работы tail . Вот эта команда:
Вот как вывод этой команды выглядит на моём компьютере.
Результаты работы команды less
Обратите внимание на то, что в нижней части экрана имеется надпись Waiting for data… . В данный момент утилита less работает практически так же, как и tail . Но если нажать CTRL+C — произойдёт кое-что интересное. Ну — что-то, возможно, и произойдёт. Попробуйте. Если less переходит в командный режим — значит всё в порядке. Теперь можно заниматься всем тем, чем обычно занимаются, просматривая файлы с помощью less . Если же по нажатию CTRL+C работа less прекратится, это будет означать, что ваш Linux-дистрибутив «помог» вам, установив некоторые стандартные опции less с использованием переменной окружения LESS . Попробуйте такую команду:
Если вы увидите, что в списке опций имеется --quit-on-intr , это будет значить, что проблема заключается именно в данной строке. Её надо убрать. После этого переключиться в командный режим можно с использованием CTRL+C . Это, кроме того, означает, что вам нужно запомнить, что для выхода из less используется команда q . Если вы вышли из режима наблюдения за файлом и хотите снова в него вернуться — просто нажмите F .
Если вы пользуетесь less в обычном режиме (то есть — не использовали при запуске утилиты опцию +F ), вы можете нажать клавишу F на клавиатуре для перехода в «tail-режим». А ещё интереснее то, что, нажав ESC-F можно в этом режиме что-то искать, при этом, если в поступающих данных найдётся совпадение с тем, что вас интересует, система вам об этом сообщит.
Команду less можно ещё использовать с ключом --follow-name . Это позволит добиться того же эффекта, что и использование опции -F команды tail .
Наблюдение за файлами с помощью команды watch
Иногда файл, за которым нужно наблюдать, не пополняется новыми данными, добавляемыми в его конец, а просто иногда меняется. Например, это файл /proc/loadavg или многие другие файлы из директории /proc . Использование команд tail или less не особенно хорошо подходит для наблюдения за такими файлами. Тут нам на помощь придёт команда watch :
Результат выполнения команды watch
Эта команда вызывает cat каждые 5 секунд и аккуратно выводит результат. Команда watch поддерживает множество полезных опций. Например, опция -d позволяет выделять отличия, а -p позволяет задействовать высокоточный таймер. Опция -c включает поддержку цвета.
Использование текстового редактора для наблюдения за файлами
Возможно, используемый вами текстовой редактор поддерживает tail-режим. При работе с emacs , например, есть несколько способов это организовать. Не буду рассказывать о том, как это сделать. Просто порекомендую вам эту отличную статью. Я не отношу себя к экспертам в области vim , но полагаю, что если вы пользуетесь этим редактором и хотите наблюдать за файлами, вам понадобится специальный плагин.
Если вы не ищете лёгких путей, то вам, возможно, подойдёт инструмент наподобие lnav, который сделан специально для просмотра логов. Просмотрщики журналов имеются, кроме того, в KDE и Gnome.
Итоги
Как это обычно бывает в Linux и Unix, у задачи организации наблюдения за файлами есть множество решений. Какое из этих решений «лучше» других? У каждого будет собственный ответ на этот вопрос. Именно это и делает Linux системой, привлекательной для продвинутых пользователей. Каждый из них может выбрать именно то, что подходит ему лучше всего.
Те команды, о которых мы говорили, могут пригодиться и тем, кто пользуется настольным дистрибутивом Linux, и тем, кто работает с серверами или с Raspberry Pi.
В Linux имеется платформа аудита, которая позволяет узнать обо всех случаях доступа к файлу, его изменениях или запуске. Также можно вести наблюдение за изменением целых директорий.
Как установить auditd (auditctl)
В Debian, Linux Mint, Kali Linux, Ubuntu и их производных для установки выполните команду:
В Arch Linux, Manjaro, BlackArch и их производных данный пакет называется audit и входит в core репозиторий, следовательно, он предустановлен по умолчанию.
В CentOS для установки выполните команду:
Как запустить монитор доступа и изменений файла
Необходимо начать с добавления правил. Следующая команда добавляет монитор доступа и изменения файла /etc/resolv.conf:
Это пример команды с другой нотацией, но выполняет она идентичное действие — мониторит все изменения и доступ к файлу /etc/resolv.conf:
Проверить, какие правила добавлены, можно следующей командой:
Хотя правило добавлено, служба аудита ещё не запущена. Для её запуска выполните команду:
Если вы хотите добавить данную службу в автозагрузку, то выполните:
Запуск auditd без перевода в фон
Предыдущая команда запустит auditd как демон, то есть служба в фоне. Если вам это не нужно и вы хотите запустить auditd на переднем плане, то вместо использования systemctl выполните следующую команду:
В этом случае все события с отслеживаемыми файлами или папками будут отображаться в стандартном выводе. При этом файл журнала не будет вестись.
Это полезно при отладке правил, либо если вам нужно проследить за событиями в короткий промежуток времени.
Как просмотреть журнал auditd
Журнал auditd хранится в файле /var/log/audit/audit.log. Но вместо того, что просматривать его напрямую, можно воспользоваться утилитой ausearch, например:
Если будет выведено
значит данный файл ещё не трогала ни одна программа.
Если события произошли, там будут примерно следующие записи:
Чтобы узнать, какая программа выполнила действие, смотрите строку «exe=».
Как остановить службу auditd
Чтобы удалить службу из автозагрузки, выполните команду:
Если вы попытаетесь остановить службу следующей командой:
Для остановки службы выполните команду:
Как удалить все правила отслеживания изменений папок и файлов
Чтобы удалить сразу все правила, выполните команду:
Возможно удаление отдельных правил (как по отслеживаемому событию, так и по привязанному идентификатору).
Ошибка «Error opening /var/log/audit/audit.log (Нет такого файла или каталога)»
Если вы получили ошибку
То она означает, что служба audit не была запущена (вы забыли её запустить, она не запустилась из-за ошибки, либо вы запустили её на переднем плане).
Примеры настройки auditd
Чтобы посмотреть все системные вызовы, сделанные определённой программой:
Чтобы увидеть файлы, открываемые определённым пользователем:
Чтобы увидеть неудачные вызовы openat:
Для слежения за изменениями файла (два способа выражения):
Для рекурсивного слежения за директорией на предмет изменений (два способа выражения):
Чтобы посмотреть, получал ли администратор доступ к файлам пользователя:
Файлы auditd
Документация по auditd
В данной статье показано, как начать использовать auditd для отслеживания изменений в файле и отслеживанию доступа к файлу.
Возможности auditd не исчерпываются показанными примерами и имеется несколько утилит, с множеством настроек и опций, которые позволяют очень гибко настраивать правила мониторинга происходящего в файловой системе, а также выполнять другие сопутствующие действий.
С помощью man вы можете ознакомиться со следующей документацией:
Читайте также: