4 ms·

How does pass solve this problem? Surely entering "command `pass accountdata`" has the same problem that the secret shows up in ps as command's argument.

• okamiueru 5y ago
  I see. I should have read the article more closely before commenting. I made a bad assumption based on the comments I saw here. The article is more about avoiding leaking the password than actually dealing with managing passwords in command lines. A few comments on the actual article, which was a lot more insightful than I had thought: - Protecting yourself from an audit logs is not really worth the effort, as the audit log should be treated as confidential as the secrets themselves. - Utilities can themselves hide arguments, and will not show on the ps output. For example, `mysqlsh` shows as `--password=********`, as does `mysql`. I'm not 100% if modifying argv data has any effect on /proc, but then again, if you are protecting yourself from something that can access /proc (i.e. root), then nothing will work in the end. Protecting yourself from a rogue process that can monitor `ps` is also already a lost battle.
  • Hello71 5y ago
    > if you are protecting yourself from something that can access /proc (i.e. root) on Linux and all other Unix-like systems I know of, all users are allowed to list running processes and their command lines. > Protecting yourself from a rogue process that can monitor `ps` is also already a lost battle. ps is not a privileged command on most systems. POSIX says "On some implementations, especially multi-level secure systems, ps may be severely restricted and produce information only about child processes owned by the user."; "severely restricted" implies that this is not a common behavior. furthermore, the article explains clearly how to hide secret arguments from ps. that's the main point of the article.