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.

user3840170
  • 1,832
Lax
  • 69
  • 1
  • 4

2 Answers2

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.

Gilles 'SO- stop being evil'
  • 829,060
  • 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 – Lax May 11 '23 at 06: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. – rotten May 19 '23 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. – Gilles 'SO- stop being evil' May 20 '23 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.) – rotten May 22 '23 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. – Gilles 'SO- stop being evil' May 22 '23 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.

telcoM
  • 96,466