On Wednesday, 26 March 2014, at 1:38 pm, Cristian Ionescu-Idbohrn wrote: > On Wed, 26 Mar 2014, Matt Whitlock wrote: > > Tons of programs modify their argv arrays. > > Alright, you know better.
It's common for programs that accept sensitive information (such as passwords) via command-line arguments to null out those arguments so they can't be read via /proc/<pid>/cmdline or 'ps'. > > Anything that uses strtok to split arguments at delimiters will do > > it. > > Yes, there's still much to learn. Do you happen to know of some > popular examples? Mplayer comes to mind immediately, as the suboptions for its filters are typically delimited with colons on the command line, but those suboptions then get parsed apart. > > One should never assume that /proc/<pid>/cmdline will contain > > the command line as it was originally used to execute the process. > > Do you happen to know of some reliable reference text stating that? I've been looking around a little, but all the sources I've found explaining what /proc/<pid>/cmdline is just say it gives the arguments used to start the process. While it's true that cmdline does return the bytes at the location of the arguments that were used to start the process, it's not guaranteed that those bytes are unaltered since the process was started. That's the reason one should never assume. The argv parameter to the main function in a C program is passed as a pointer to an array of pointers to *non-constant* characters, meaning the program is given explicit permission to modify those characters however it likes. The kernel does not make a backup of the contents of the argument array passed to execve, so cmdline reads from the only copy of those arguments that is available, which is the copy that has been passed to the executed process, which is free to change those bytes. It's worth mentioning that this is exactly the same behavior as /proc/<pid>/environ, whic h contains the environment of the process, which the process is free to change at will as well, and which changes will be reflected in /proc/<pid>/environ. _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
