Some applications allow to pass password as an argument. For example:

mysql --user=user_name --password=your_password db_name

Is it safe? Besides the fact that typed password would be saved in bash history, someone can type w command in the appropriate moment and will see the full command line of process (including password).

It's quite surprising for me that every user can see what command I'm currently executing.

  • 2
    No, it's not safe. See my answer here: unix.stackexchange.com/questions/158933/… Oct 5, 2014 at 18:59
  • 2
    See also ps -ef (all running processes) for example. Or the contents of /proc. It's not just the w command that's special here; what processes are running on the system is considered to be public knowledge for everyone on that system. Oct 5, 2014 at 19:38
  • If you don't want to let bash save those commands in the history just begin the command with a space: $echo 'a' a $ echo 'b' b $!echo echo 'a' a (note that echo 'b' was not recorded in the history).
    – Bakuriu
    Oct 6, 2014 at 13:10

3 Answers 3


The command line arguments of every process in the system is considered "public". Not just the w command, but ps and top and many other commands access that information as a matter of course. Indeed no special privileges are required to get that information. On Linux, you can read the command line of another process, even a process belonging to another user, by reading /proc/<pid>/cmdline.

This is not a flaw or unsafe behaviour on the part of w or top or ps (or cat). Rather, the onus is on the side of not passing sensitive information on command lines on multi-user systems, ever.

Most utilities that have the ability to accept passwords on the command line document that it's not recommended to do it. For example, from mysql's manpage:

Specifying a password on the command line should be considered insecure. See Section, "End-User Guidelines for Password Security". You can use an option file to avoid giving the password on the command line.

By the way, passing passwords or sensitive data in environment variables is less blatantly unsafe, but is also actually unsafe on most systems.

  • 2
    mysql actually overwrites the password argument (see unix.stackexchange.com/q/88665/15241 ), but this does not really solve the security problem.
    – jofel
    Oct 6, 2014 at 9:09
  • Nice quote from zip manual (see --password option): (...) Many multi-user operating systems provide ways for any user to see the current command line of any other user; even on standalone systems there is always the threat of over-the-shoulder peeking. Storing the plaintext password as part of a command line in an automated script is even worse. Whenever possible, use the non-echoing, interactive prompt to enter passwords. (...). Jun 22, 2015 at 10:04

No, it's not safe to pass passwords to programs on the commandline. It's better to use:

mohsen@debian:~$ mysql -uuser -p
Enter password: 
  • I know that it's preferred way of passing password but sometimes (i.e. in bash script) I need to use hardcoded password. Oct 5, 2014 at 21:23
  • I remmeber postgresql has a way for reading password securely, search for that, may be mysql has same mechanism too. Oct 5, 2014 at 23:11

While it is not safe, please remember that Linux these days is in its early twenties - like with other things in IT the security implications were either not that clear back then or addressed later on.

Hence, as mentioned in the other answers, do not use password on the command line.

You can (and probably shold) also restrict the information provided by either mountring procfs with thehidepid` option, or using the grsecurity hardened kernel. Note that this might break some things (possibly cgroups and anything that relies on them - like e.g. systemd), at least at the time of writing this.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .