Martin Bernreuther wrote: > on a common Linux system, everyone can use e.g. > ps and will see running processes of all users including > the command line arguments.
Yes. This is a long standing reason that programs that deal with secure data such as passwords should avoid putting passwords in the argument list, for example. > I'd like to hide the command line arguments e.g. for the cp command, > which sometimes uses quite a long time to copy large files, to keep > the path and file names secret. I suggest using the 'rsync --from0 --files-from=FILE' options. This will read a list of files (optionally from stdin if FILE is "-") and therefore the filenames will never appear in the argument list of the process. Another alternative is to use the 'cp -R' to copy a directory of files. In that case cp reads the directory listing itself and therefore the filenames are never in the argument list. > Writing a small C program, it's quite easy to > overwrite all chars of the argv[] strings with 0 > after the commandline options are being processed. > > Is there a possibility to activate such a feature > in e.g. cp? (like cp --hideargs ...) Unfortunately that doesn't really work. If a ps is done very quickly after the program starts but before it can obscure the argument list then the values are still seen. It reduces the time that arguments are exposed but this creates a false sense of security. This false sense of security may be worse because it would lead people to believe they are safe when they are not. If you really need to hide the files then it is better to solve the problem 100% and _never_ put the filename in the argument list. That means that the list of files needs to read by the program by other means. Either by having the program read the directory itself or by passing it a list through the environment or by passing it a list by file. The rsync command seems perfectly fitted to this task. Although I will admit that sending the list of files to copy to it through a file/stdin is slightly more involved than cp. But here since you are wanting more then a little more work to get it seems reasonable. Bob _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils