3 ms·

To me it actually sounds like a better approach than blindly following "everything is a file" mantra.

kjeetgill 2y ago
I'm totally with you for processes should probably use glibc/platform API calls, but procfs is nothing short of brilliant and a great validation of the power of the "everything is a file".
- Sophira 2y ago
  Except that any process that has obtained root (through a security flaw or otherwise) can extremely easily hide itself, as shown here. I will admit that it's likely that the same thing could be done with loadable kernel modules, that said.
yjftsjthsd-h 2y ago
What's blind about it? Reading files is nicer than parsing ps output or needing to write native code over a syscall.
- jcranmer 2y ago
  Trying to parse the output of several procfs files isn't as easy as it looks. The per-pid maps file for one (smaps is even worse). Much better if I could just get a struct with all this information.
  - 0xedd 2y ago
    Asking DevOps to program for basic tasks. Cool story, bro.
  - djbusby 2y ago
    I've not looked at kernel source but, when I had a task to read info from /proc it looked like a lot of info was just pack() in there. So my parsing was just done with unpack(). Mapping those values from things that could be found in existing userland tools.
- zokier 2y ago
  One problem with reading /proc is that its impossible to get consistent view of the whole system because you are iterating the processes one by one, instead of getting snapshot of all the processes.
  - yjftsjthsd-h 2y ago
    Is there an OS that provides the whole result of ps(1) or equivalent in one syscall? I was under the impression that it was ~always iteration based.
    - zokier 2y ago
      On NT you can get this sort of stuff through WMI, although I'll admit it's not entirely clear to me how that resolves internally
      - yjftsjthsd-h 2y ago
        I guess my point/question was more - is whatever system/library call you'd use atomic? There's technically no reason the system couldn't have a syscall that returns a full data structure of process info for as many processes as are in scope and guarantee that it's a perfect atomic snapshot of exactly how the process table looked when that call returned, but I'd want to be very confident and have explicit documentation promising as much before I depended on it.
- deepsun 2y ago
  The problems are: "what file?", "what format?", "merge data from multiple files". Not sure if relevant to this discussion, but here's the problems I've experienced working with files for system devices: [1] here's just a discovery of a logitech mouse receiver, notice that it touches: * /sys/class/* * /sys/module/* * /sys/class/hidraw/*/device/driver I must take care that each dir might not be present, symlinks may be dangling, and access to multiple files is not atomic. It would be much easier and stable using just one SQLite query, for example. [1] https://github.com/Lekensteyn/ltunify/blob/master/ltunify.c#L1164 https://github.com/Lekensteyn/ltunify/blob/master/ltunify.c#...

I'm totally with you for processes should probably use glibc/platform API calls, but procfs is nothing short of brilliant and a great validation of the power of the "everything is a file".

Sophira 2y ago
Except that any process that has obtained root (through a security flaw or otherwise) can extremely easily hide itself, as shown here. I will admit that it's likely that the same thing could be done with loadable kernel modules, that said.

yjftsjthsd-h 2y ago

What's blind about it? Reading files is nicer than parsing ps output or needing to write native code over a syscall.

jcranmer 2y ago
Trying to parse the output of several procfs files isn't as easy as it looks. The per-pid maps file for one (smaps is even worse). Much better if I could just get a struct with all this information.
- 0xedd 2y ago
  Asking DevOps to program for basic tasks. Cool story, bro.
- djbusby 2y ago
  I've not looked at kernel source but, when I had a task to read info from /proc it looked like a lot of info was just pack() in there. So my parsing was just done with unpack(). Mapping those values from things that could be found in existing userland tools.
zokier 2y ago
One problem with reading /proc is that its impossible to get consistent view of the whole system because you are iterating the processes one by one, instead of getting snapshot of all the processes.
- yjftsjthsd-h 2y ago
  Is there an OS that provides the whole result of ps(1) or equivalent in one syscall? I was under the impression that it was ~always iteration based.
  - zokier 2y ago
    On NT you can get this sort of stuff through WMI, although I'll admit it's not entirely clear to me how that resolves internally
    - yjftsjthsd-h 2y ago
      I guess my point/question was more - is whatever system/library call you'd use atomic? There's technically no reason the system couldn't have a syscall that returns a full data structure of process info for as many processes as are in scope and guarantee that it's a perfect atomic snapshot of exactly how the process table looked when that call returned, but I'd want to be very confident and have explicit documentation promising as much before I depended on it.
deepsun 2y ago
The problems are: "what file?", "what format?", "merge data from multiple files". Not sure if relevant to this discussion, but here's the problems I've experienced working with files for system devices: [1] here's just a discovery of a logitech mouse receiver, notice that it touches: * /sys/class/* * /sys/module/* * /sys/class/hidraw/*/device/driver I must take care that each dir might not be present, symlinks may be dangling, and access to multiple files is not atomic. It would be much easier and stable using just one SQLite query, for example. [1] https://github.com/Lekensteyn/ltunify/blob/master/ltunify.c#L1164 https://github.com/Lekensteyn/ltunify/blob/master/ltunify.c#...