Linux – Why is UID information not in /proc/X/stat

linuxproc

This is a silly question for the sake of academics; I know where to get the UID information if I need it. According to the proc(5) man page:

       /proc/[number]/stat
              Status information about the process.  This is used by ps(1).  It is defined in /usr/src/linux/fs/proc/array.c.

       /proc/[number]/statm
              Provides information about memory status in pages.  The columns are:

       /proc/[number]/status
              Provides much of the information in /proc/[number]/stat and /proc/[number]/statm in a format that’s easier for humans to parse.

I find it interesting that stat doesn't contain information about the UID, EUID, etc. of a process, yet status does. Kind of odd that one is forced to use the "human readable" file instead. Does anyone happen to know the reason for this off-hand?

Best Answer

When handling data, much of the time, the key is to keep only data that's relevant to your particular set of tasks, and nothing more. Much of the data that's exposed under /proc is done so for a singular purpose, i.e. a tool that needs to have visibility to it etc.

Given the comments I would assume 3 things about /proc/[number]/stat:

  1. The data being displayed here is what's relevant to functions and data objects within /usr/src/linux/fs/proc/array.c.
  2. That data is also what's relevant to ps.
  3. Looking through the data that's here you'll notice that there is nothing here that's user specific. It's all geared towards processes.

NOTE: for #2. this is the process data that's relevant to ps. The processes owned by a user are kept in a different data structure within the Kernel elsewhere.

On the otherhand, with /proc/[number]/status, the comment pretty much tells you what this data is geared towards, a human reading it. So it's likely that this node within the Kernel serves no other purpose, from a tools perspective, then to collate data from other sources into a single place for the user to consume it.

Additional evidence

If you need more proof of this, look to this question I answered a while ago, titled: /proc/meminfo MemTotal =?. This question covered /proc/meminfo and it was a similar issue here too. Some of the data is exposed during the Kernel boot-up under dmesg log output. However that data, though memory related and perceived as relevant to /proc/meminfo was absent, again because it wasn't useful to:

  1. the target audience of tools that would be using /proc/meminfo
  2. Not relevant to the Kernel internal functions, methods, and data structures that made use of the data in /proc/meminfo.

References

Related Question