26

Which command allows me to know if my webcam is used or not?

lsof /dev/video0 is not sufficient. All block devices with major and minor number 81 and 0 should be monitored.

user123456
  • 5,018
  • 2
    +1. TIL lsof (and fuser) doesn't by default do what you need it to. – Celada Feb 12 '17 at 19:28
  • @celada could you please explain ? – YoungFrog Feb 12 '17 at 20:53
  • What are your concerns? Is it video watching you, or are you also worried about audio (in which case covering the lens would not solve your problem)? Or is it about debugging or even curiosity?# – Chris H Feb 13 '17 at 14:10
  • @YoungFrog I was just complimenting the OP on this question because it made me learn something. I initially assumed that lsof /dev/video0 would like all processes that were holding an open file descriptor connected to the kernel vfs object that /dev/video0 refers to, no matter which filesystem path had been used to open it, but the OP's question makes it clear that this is not true. – Celada Feb 18 '17 at 00:50

3 Answers3

30

If your kernel uses modules (which is highly likely), one way to determine whether a program is accessing your webcam is to look at the usage count of the module:

$ lsmod | grep uvcvideo
uvcvideo               90112  0

The 0 in the third field shows that nothing has any device open for a uvcvideo-controlled webcam (when lsmod ran). Of course you need to know exactly which module is responsible for your webcam; it's easy to check though, you'll see the output change while running a program such as Cheese.

Note that, strictly speaking, a positive count only means that something has opened a device, it doesn't mean images are being captured.

Stephen Kitt
  • 434,908
  • Doesn't a positive count also only mean that something has such a device open now, as opposed to may be opening it for a fraction of a second to capture an image and then close it? With such a usage pattern, you'd have to be incredibly lucky to catch it in the act. – user Feb 13 '17 at 09:57
  • @MichaelKjörling that's why I mentioned "when lsmod ran". It does deserve expansion given the scenario you give (although in my experience, cameras' latencies are high enough that opening the device, capturing an image and closing the device takes quite a while). Looking at device usage using fuser or lsof suffers from the same issue though; a more robust approach would require hooking the V4L APIs using tracepoints or something similar. – Stephen Kitt Feb 13 '17 at 10:06
  • @MichaelKjörling Indeed. To capture this usage pattern, you'd have to monitor accesses to the device file(s), not just check at one point in time. – Gilles 'SO- stop being evil' Feb 13 '17 at 13:11
14

On any sane system, unless you have set up chroots with their own /dev, all device files are under /dev. Only root can create device files, so you don't need to worry about malicious users creating device files elsewhere.

So all you need to do is locate the files under /dev that refer to the same device as the one you're interested in.

ls -lR /dev |awk '/^c/ && $5 == "81," && $6 == "0"'

It's likely that this will show only /dev/video0. Usually, there's a single device file for each device, and there are possibly additional symbolic links to it.

Thus the practical answer to your question is the simple one. Just check what processes have the device file open.

fuser /dev/video0

If you want to monitor accesses (i.e. catch processes that may open the device file at any time), use one of Linux's file access monitoring methods on the device file(s): set up a watch (and check what processes already have the device file(s) open)

inotifywait -m -e open,close /dev/video0 &
sleep 1; fuser /dev/video0   # check for processes that have already opened the device

or set up an audit rule which will log accesses in the system logs (typically /var/log/audit/audit.log)

auditctl -w /dev/video0 &
sleep 1; fuser /dev/video0   # check for processes that have already opened the device
  • Good point! But, it still suffers from the point-in-time problem of Angel!'s solution (cf. comments there). The most robust software solution is probably to blacklist that device in udev so it doesn't get a device file at boot up; and then add a device file if and when you plan to use the camera... or physically unplug it. – jpaugh Feb 13 '17 at 12:40
  • 1
    @jpaugh The question was finding processes using the webcam, not disabling the webcam. – Gilles 'SO- stop being evil' Feb 13 '17 at 13:10
  • It should be monitor at the Kernel level. A device can be added anywhere: e.g mknod /root/video0 b 81 0 – user123456 Feb 14 '17 at 12:52
  • @j658063.mvrht.com But only root can do that. If root doesn't do stupid things then you're safe. If root does stupid things then you're screwed anyway — root can also change the kernel to hide some processes. – Gilles 'SO- stop being evil' Feb 14 '17 at 13:00
7

Assuming that what you actually want is to make sure your webcam isn't being used when you don't want it to, the simplest solution is to simply disconnect it (if external) when not needed. Or covering the webcam (just a piece of duct tape would work).

Physically-based approaches are much more secure than software ones.

Ángel
  • 3,589
  • 2
    Tape doesn't block the microphone, which can (even on a builtin webcam) be structured as part of the camera rather than through a sound module. – Chris H Feb 13 '17 at 09:48
  • I would strongly advice against duct tape as it could easily leave a residue. I have used surgical tape (available from drug stores) because it leaves very little residue when removed, with a small sticker covering the lens, sticky side to sticky side. That way there is no risk of glue residue on the lens. It is, admittedly, a solution that is slightly on the permanent side; you don't want to take off and put back on tape all the time. – user Feb 13 '17 at 09:49
  • @ChrisH that doesn't make any sense (ironically, your top SE is English...) What do you mean? – minseong Feb 13 '17 at 11:00
  • @theonlygusti I meant module as in a piece of hardware; of course on this thread it would be more logical to read it as meaning software, which wouldn't make much sense. Tape doesn't block the microphone. A microphone can be part of the webcam hardware, instead of or in addition to anything connected through the sound card (a term I was avoiding because of SoC hardware). So to determine whether the webcam is enabled/active/spying you might be concerned about more than just the lens. But the only linux system I have here is a chromebook (crouton) so a bit limited. – Chris H Feb 13 '17 at 11:49
  • @ChrisH I suppose the best solution there is to tape a fragment of sound-proofing material over the microphone; but internal vibrations could still be picked up, which might be the echos of external vibrations (e.g. your conversation). – jpaugh Feb 13 '17 at 12:37
  • 2
    Sure, but that wasn't the question – Gilles 'SO- stop being evil' Feb 13 '17 at 13:11
  • Wow really? Just disable it... why would you tape over it? If you disable the device it cannot be used. To be extra sure un-install the driver/module – Milney Feb 13 '17 at 13:27
  • @jpaugh I considered (on an old laptop) disconnecting the webcam inside and repurposing the USB line for a bluetooth adaptor. The laptop died before I got that far. – Chris H Feb 13 '17 at 14:08
  • @Gilles the question didn't go in to that much detail, I'll comment underneath asking just that point. – Chris H Feb 13 '17 at 14:08
  • I know someone who would always stick a post-it on the camera whenever they used my latop. It didn't leave a residue. I thought it was a bit paranoid. However, such an approach is more time efficient and reassuring, even for techies/power users, and she was not one. It's a cross platform, KISS solution. Who can blame you for Keeping It Simple and proactively protecting your privacy? – Rolf Jan 30 '18 at 12:05
  • I also made a quick search on ebay, and sure enough someone already invented camera "privacy shutters" and they are made in china. However, when we are so removed and distrustful from what happens inside our devices that we need to add such things to them, it says something. – Rolf Jan 30 '18 at 12:14