6

A question about this command from half a decade ago claims that lsof does not monitor all the processes using cam. But when I ran the command while running testcam I got:

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
firefox-b 3077  lax  mem    CHR   81,0           808 /dev/video0
firefox-b 3077  lax  143u   CHR   81,0      0t0  808 /dev/video0

What does the DEVICE 81,0 indicate. I can't quite understand how it's not being monitored since its displaying blocks 81,0.

2 Answers 2

18

lsof /dev/video0 only lists processes that have /dev/video0 open. Suppose that the administrator runs this command:

mknod /somewhere/else c 81 0

Then a program can use the camera device through the device file /somewhere/else. This access won't be visible with lsof /dev/video0, but will be visible with lsof /somewhere/else.

Only root can create device nodes. On a normal system, /dev/video0 is the only device file for the webcam. So in practice, lsof /dev/video0 does list all processes accessing the webcam.

5
  • right. So this question was based on an application i was building to track cam usage. hence if the root user has created custom devices files accessing the cams it has to create a symbolic link to dev/video0. This makes solid sense! Thanks a lot Commented May 11, 2023 at 6:28
  • So you could do something like sudo find / -type c -ls | grep 81, 2>/dev/null to find all of the places where there might be an existing camera node and then lsof all of them. Commented May 19, 2023 at 15:29
  • 2
    @rotten Yes, but if you start down that path, this is still not guaranteed to find all of them. A process could be accessing a now-deleted inode referencing the same device. Commented May 20, 2023 at 19:30
  • So a process could mknod the device, connect to it, then spin off another process that deletes the node from the file system, but it still hangs on to it in the original thread. Surely there is a way to list open files that have been deleted from the file system? (And normally one wouldn't expect to find too many of them - especially after a reboot.) Commented May 22, 2023 at 13:50
  • 1
    @rotten You can traverse /proc/*/files or have lsof do it for you. One would not normally ever expect that for a device file. Commented May 22, 2023 at 17:13
14

DEVICE 81,0 does not refer to blocks at all: together with TYPE CHR it indicates this device is a character device with major number 81 and minor number 0.

From /proc/devices, you can see that character device major number 81 is associated with the video4linux subsystem. The minor numbers are assigned by each subsystem as they see fit: in this case, the minor number is directly reflected in the device name /dev/video0 generated by udev.

Classically, unix-like systems used the machine-friendly device numbers as the primary internal identifiers for devices, rather than human-friendly device names. The entire /dev directory tree with its device nodes is basically a big look-up table that allows the kernel's filesystem drivers to convert device names to device numbers, much like the /etc/services file allows you to use a port name like ssh or ntp instead of port numbers like 22 or 123, respectively. Device nodes can also have permissions, which is also very useful for restricting inappropriate access to device drivers.

When you run lsof as a regular user, it may output information about your own processes only: a regular user has no business snooping on other users. Root privileges are required to see what other users' processes are doing.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.