Maybe I haven't had enough coffee yet today, but I can't remember or think of any reason why /proc/PID/cmdline should be world-readable - after all, /proc/PID/environ isn't.

Making it readable only by the user (and maybe the group. and root, of course) would prevent casual exposure of passwords entered as command-line arguments.

Sure, it would affect other users running ps and htop and the like - but that's a good thing, right? That would be the point of not making it world-readable.

  • 4
    one thing to note: passwd can easily be hidden in interactive commands. for ex: some_cmd -p "thepwdhere" ... can be instead done as : some_cmd -p "$(cat)" ..., and enter your password with: thepwdhere<Enter><ctrl-d>. Could come in handy sometimes... (to hide it even in your own history, so that if you show (or copy-paste) it to show to colleagues, it doesn't show the password used, for exemple) Oct 18 at 14:10
  • 17
    @OlivierDulac that doesn't actually keep it out of the process's /proc/pid/cmdline. The shell runs the cat command substitution and inserts cat's output into the command line. Works fine for keeping a password or whatever out of the shell history, but not for stopping it being visible in ps or top etc.
    – cas
    Oct 18 at 14:17
  • 2
    @cas Good point (relevant to the question asked), I was principally focusing on the history file Oct 18 at 14:18
  • 1
    @MarcusMüller, yep. Though at least for that use, /proc/cmdline probably wouldn't need to be readable by anyone else but root.
    – ilkkachu
    Oct 18 at 16:35
  • 4
    Presumably you're implicitly asking why ps -ef can return information for other users' command lines too
    – roaima
    Oct 18 at 21:23

I suspect the main, and perhaps only, reason is historical — /proc/.../cmdline was initially world-readable, so it remains that way for backwards compatibility. cmdline was added in 0.98.6, released on December 2, 1992, with mode 444; the changelog says

     - /proc filesystem extensions.  Based on ideas (and some code) by
       Darren Senn, but mostly written by yours truly.  More about that

I don’t know when “later” was; as far as I can tell, Darren Senn’s ideas are lost in the mists of time.

environ is an interesting counter-example to the backwards compatibility argument: it started out word-readable, but was made readable only by its owner in 1.1.85. I haven’t found the changelog for that so I don’t know what the reasoning was.

The overall accessibility and visibility of /proc/${pid} (including /proc/${pid}/cmdline) can be controlled using proc’s hidepid mount option, which was added in version 3.3 of the kernel. The gid mount option can be used to give full access to a specific group, e.g. so that monitoring processes can still see everything without running as root.

  • 8
    oh, nice! i wasn't aware of the hidepid mount option.
    – cas
    Oct 18 at 4:39
  • 1
    Having /proc/.../environ locked down is necessary if you're using variables like AWS_SECRET_ACCESS_KEY or MYSQL_PWD to simplify access. Not a good idea generally but some people use these variables.
    – doneal24
    Oct 18 at 17:17
  • 1
    @doneal24 yes, and the same argument applies to cmdline (with the same caveat). Oct 18 at 18:23
  • 3
    AIUI, the permissions change on environ was done because the info there was never public info on traditional UNIX systems (unlike a process’s command line), so anything relying on it being public was inherently not portable to begin with, and some applications already relied on their environment not being public knowledge for security reasons. Early on, existing parts of the Linux ABI were not as immutable as they are today, and decisions like this were sometimes made to ensure consistency with other platforms when there were such security related considerations. Oct 19 at 1:47
  • 3
    @Austin AFAIK the BSDs considered that the environment was public info — at least, BSD ps could display it. Oct 19 at 6:40

The command line of the processes has always been considered public information in Unix and was always available via the ps(1) command. The environment of a process, on the contrary, was never such public information.

In the original Unix implementation, ps was a setuid executable which was opening /dev/mem and extracting all the information directly from the live memory of the kernel, in the manner of a debugger. Linux supported a plan9-alike /proc filesystem since early on, and ps was implemented as a simple non-setuid program which was just opening and reading files like /proc/<pid>/stat and /proc/<pid>/cmdline. Since those were meant both as the regular kernel/user interface for obtaining that info, and as a shell-friendly alternative to parsing the output of ps (yuck), they could not be and it made no sense to be more restrictive than ps.

Sure, it would affect other users running ps and htop and the like - but that's a good thing, right? That would be the point of not making it world-readable.

No it's not a good thing. Besides breaking the standard (see the link above) that will make the system un-debuggable without root privileges, and the security advantages of that would be at best illusory. (Notice that at the time where Unix was invented, security through obscurity and free speech restrictions weren't yet as fashionable as they are today.)

You don't have to imagine what such a Linux system would look like -- there's already Android which a non-rooted system is a nasty black box (locked down in all possible ways, not just with hidepid) for its actual user(s), yet in no way more robust against external attackers and data collectors than a typical Debian or Slackware desktop or server.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jeff Schaller
    Oct 19 at 14:36
  • @JeffSchaller For some reason, I don't seem to have access to that chatroom link, and I would like to browse it. Any suggestions for those of us in this situation?
    – jrw32982
    Oct 27 at 17:34
  • @jrw32982 that chat room became inactive and was deleted automatically (about 18 hours ago as I write this).
    – Jeff Schaller
    Oct 27 at 17:57
  • Thanks for that update, @JeffSchaller. Not sure why the chat can't be permanent. :-( I was interested on more discussion about the nasty Android black box from user497439
    – jrw32982
    Oct 27 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.