+1. TIL lsof(и fuser) по умолчанию не делает то, что вам нужно.
Селада
@celada не могли бы вы объяснить?
YoungFrog
Каковы ваши проблемы? Это видео смотрит на вас, или вы также беспокоитесь о звуке (в этом случае покрытие объектива не решит вашу проблему)? Или это отладка или даже любопытство? #
Крис Х
@YoungFrog Я просто дополнял ОП по этому вопросу, потому что он заставил меня чему-то научиться. Сначала я предположил, что lsof /dev/video0хотел бы, чтобы все процессы, которые содержали дескриптор открытого файла, подключались к объекту vfs ядра, на который /dev/video0ссылается, независимо от того, какой путь файловой системы использовался для его открытия, но вопрос OP проясняет, что это не так.
Селада
Ответы:
15
Если ваше ядро использует модули (что весьма вероятно), один из способов определить, обращается ли программа к вашей веб-камере, - это посмотреть счетчик использования модуля:
$ lsmod | grep uvcvideo
uvcvideo 90112 0
0 в третьем поле показывает, что ничто не имеет открытого устройства для uvcvideoуправляемой веб-камеры (при lsmodзапуске). Конечно, вам нужно точно знать, какой модуль отвечает за вашу веб-камеру; хотя это легко проверить, вы увидите изменение выхода при запуске такой программы, как Cheese.
Обратите внимание, что, строго говоря, положительный счет только означает, что что-то открыло устройство, это не означает, что изображения захватываются.
Разве положительный счет также не означает только, что у такого устройства сейчас есть такое открытое устройство , в отличие от того, чтобы открывать его на долю секунды, чтобы захватить изображение, а затем закрыть его? С такой схемой использования вам бы невероятно повезло поймать ее в действии.
CVn
@ MichaelKjörling, поэтому я упомянул "когда lsmodпобежал". Это действительно заслуживает расширения, учитывая сценарий, который вы даете (хотя по моему опыту, задержки камер достаточно высоки, чтобы открытие устройства, захват изображения и закрытие устройства занимало довольно много времени). Глядя на использование устройства, используя fuserили lsofстрадает от той же проблемы, хотя; более надежный подход потребует подключения API-интерфейсов V4L с использованием точек трассировки или чего-то подобного.
Стивен Китт
@ MichaelKjörling Действительно. Чтобы зафиксировать этот шаблон использования, вам необходимо отслеживать доступ к файлам устройств, а не просто проверять их в определенный момент времени.
Жиль "ТАК - перестань быть злым"
7
Предполагая, что на самом деле вам нужно убедиться, что ваша веб-камера не используется, когда вы этого не хотите , самое простое решение - просто отключить ее (если внешнюю), когда она не нужна. Или покрытие веб-камеры (просто кусок клейкой ленты будет работать).
Физические подходы намного более безопасны, чем программные.
Лента не блокирует микрофон, который можно (даже на встроенной веб-камере) структурировать как часть камеры, а не через звуковой модуль.
Крис Х
Я настоятельно рекомендую использовать клейкую ленту, так как она может легко оставить следы. Я использовал хирургическую ленту (доступную в аптеках), потому что при удалении остается очень мало остатков, с маленькой наклейкой, закрывающей линзу, липкой стороной к липкой стороне. Таким образом, нет риска остатков клея на линзе. По общему признанию, это решение немного на постоянной стороне; Вы не хотите снимать и снова записывать на пленку.
CVn
@ChrisH, это не имеет никакого смысла (по иронии судьбы, ваш топ SE - английский ...) Что вы имеете в виду?
theonlygusti
@theonlygusti Я имел в виду модуль как часть аппаратного обеспечения; конечно, в этой ветке было бы логичнее читать ее как означающую программное обеспечение, которое не имело бы особого смысла. Лента не блокирует микрофон. Микрофон может быть частью оборудования веб-камеры, вместо или в дополнение к чему-либо, подключенному через звуковую карту (термин, которого я избегал из-за оборудования SoC). Таким образом, чтобы определить, включена ли веб-камера / активна / шпионит, вас может беспокоить не только объектив. Но единственная система Linux, которая у меня есть, это Chromebook (крутон), поэтому она немного ограничена.
Крис Х
1
Конечно, но это был не вопрос
Жиль "ТАК - перестань быть злым"
7
В любой здравомыслящей системе, если вы не настроили chroots с их собственными /dev, все файлы устройств находятся под /dev. Только root может создавать файлы устройств, поэтому вам не нужно беспокоиться о том, что злоумышленники будут создавать файлы устройств в других местах.
Так что все, что вам нужно сделать, это найти файлы, /devкоторые относятся к тому же устройству, что и вы заинтересованы.
Вполне вероятно, что это покажет только /dev/video0. Обычно для каждого устройства существует отдельный файл устройства, и, возможно, существуют дополнительные символические ссылки на него.
Таким образом, практический ответ на ваш вопрос прост. Просто проверьте, какие процессы открывают файл устройства.
fuser /dev/video0
Если вы хотите контролировать доступы (т. Е. Перехватывать процессы, которые могут открыть файл устройства в любое время), используйте один из методов контроля доступа к файлам в Linux для файла (ов) устройства: настройте наблюдение (и проверьте, какие процессы уже имеют устройство файл (ы) открыт)
inotifywait -m -e open,close /dev/video0 &
sleep 1; fuser /dev/video0 # check for processes that have already opened the device
или установите правило аудита, которое будет регистрировать обращения в системных журналах (обычно /var/log/audit/audit.log)
auditctl -w path=/dev/video0 &
sleep 1; fuser /dev/video0 # check for processes that have already opened the device
Хорошая точка зрения! Но он все еще страдает от проблемы момента времени решения Angel! (См. Комментарии там). Наиболее надежное программное решение, вероятно, состоит в том, чтобы занести это устройство в черный список, udevчтобы оно не получало файл устройства при загрузке; а затем добавьте файл устройства, если и когда вы планируете использовать камеру ... или физически отключите его.
jpaugh
@jpaugh Вопрос в том, чтобы найти процессы с помощью веб-камеры, а не отключить ее.
Жиль "ТАК - перестань быть злым"
Это должен быть монитор на уровне ядра. Устройство может быть добавлено где угодно: например,mknod /root/video0 b 81 0
user123456
@ j658063.mvrht.com Но это может сделать только root. Если root не делает глупостей, тогда вы в безопасности. Если root делает глупости, то вы все равно облажались - root также может изменить ядро, чтобы скрыть некоторые процессы.
lsof(иfuser) по умолчанию не делает то, что вам нужно.lsof /dev/video0хотел бы, чтобы все процессы, которые содержали дескриптор открытого файла, подключались к объекту vfs ядра, на который/dev/video0ссылается, независимо от того, какой путь файловой системы использовался для его открытия, но вопрос OP проясняет, что это не так.Ответы:
Если ваше ядро использует модули (что весьма вероятно), один из способов определить, обращается ли программа к вашей веб-камере, - это посмотреть счетчик использования модуля:
0 в третьем поле показывает, что ничто не имеет открытого устройства для
uvcvideoуправляемой веб-камеры (приlsmodзапуске). Конечно, вам нужно точно знать, какой модуль отвечает за вашу веб-камеру; хотя это легко проверить, вы увидите изменение выхода при запуске такой программы, как Cheese.Обратите внимание, что, строго говоря, положительный счет только означает, что что-то открыло устройство, это не означает, что изображения захватываются.
источник
lsmodпобежал". Это действительно заслуживает расширения, учитывая сценарий, который вы даете (хотя по моему опыту, задержки камер достаточно высоки, чтобы открытие устройства, захват изображения и закрытие устройства занимало довольно много времени). Глядя на использование устройства, используяfuserилиlsofстрадает от той же проблемы, хотя; более надежный подход потребует подключения API-интерфейсов V4L с использованием точек трассировки или чего-то подобного.Предполагая, что на самом деле вам нужно убедиться, что ваша веб-камера не используется, когда вы этого не хотите , самое простое решение - просто отключить ее (если внешнюю), когда она не нужна. Или покрытие веб-камеры (просто кусок клейкой ленты будет работать).
Физические подходы намного более безопасны, чем программные.
источник
В любой здравомыслящей системе, если вы не настроили chroots с их собственными
/dev, все файлы устройств находятся под/dev. Только root может создавать файлы устройств, поэтому вам не нужно беспокоиться о том, что злоумышленники будут создавать файлы устройств в других местах.Так что все, что вам нужно сделать, это найти файлы,
/devкоторые относятся к тому же устройству, что и вы заинтересованы.Вполне вероятно, что это покажет только
/dev/video0. Обычно для каждого устройства существует отдельный файл устройства, и, возможно, существуют дополнительные символические ссылки на него.Таким образом, практический ответ на ваш вопрос прост. Просто проверьте, какие процессы открывают файл устройства.
Если вы хотите контролировать доступы (т. Е. Перехватывать процессы, которые могут открыть файл устройства в любое время), используйте один из методов контроля доступа к файлам в Linux для файла (ов) устройства: настройте наблюдение (и проверьте, какие процессы уже имеют устройство файл (ы) открыт)
или установите правило аудита, которое будет регистрировать обращения в системных журналах (обычно
/var/log/audit/audit.log)источник
udevчтобы оно не получало файл устройства при загрузке; а затем добавьте файл устройства, если и когда вы планируете использовать камеру ... или физически отключите его.mknod /root/video0 b 81 0