We have a CI server application run as the build user. Any command with arguments run by the CI server is visible via ps. Although non-admin users do not have access to load a shell on the CI server, they do however have access to running unix commands via a task.

My concern is; user A can potentially expose a user B's task which has command line arguments (which could potentially be sensitive info) by simply doing a ps.

Note that all tasks within the CI server is run as the build user. Users cannot switch to different user.

I could perhaps block the ps command so within a task a user cannot execute ps, which should solve my problem however I'm curious to know:

  1. Are there other commands that can be run to expose command line arguments without having root privileges?
  2. Given the context of this problem, is there a better/secure way to manage it?
  • Blocking ps is not a good idea, and then a determined user can consult proc directly. have a look at one possible answer here unix.stackexchange.com/questions/244353/… Feb 21, 2016 at 3:31
  • So all these commands are run as build? If they were run as different users, this could be done.
    – muru
    Feb 21, 2016 at 3:48
  • @RuiFRibeiro: Blocking ps for all users is probably not what I'm looking for as its vital for administering the system. Perhaps proc can be disabled too? but if there are still other means perhaps its not an efficient way to go about it. Feb 21, 2016 at 3:53
  • @muru: I'm afraid all commands are run as the build user. Feb 21, 2016 at 3:54
  • 1
    @aspiringCodeArtisan It does not block for root/sudo operations. Feb 21, 2016 at 4:08

3 Answers 3


check out the hidepid option for mounting /proc

On multi-user systems, it is often useful to secure the process directories stored in /proc/ so that they can be viewed only by the root user. You can restrict the access to these directories with the use of the hidepid option.
To change the file system parameters, you can use the mount command with the -o remount option. As root, type:

mount -o remount,hidepid=value /proc

Here, value passed to hidepid is one of:

    0 (default) — every user can read all world-readable files stored in a process directory.
    1 — users can access only their own process directories. This protects the sensitive files like cmdline, sched, or status from access by non-root users. This setting does not affect the actual file permissions.
    2 — process files are invisible to non-root users. The existence of a process can be learned by other means, but its effective UID and GID is hidden. Hiding these IDs complicates an intruder's task of gathering information about running processes. 

link for more info --

  • Unfortunately, all the processes are run as the same user.
    – muru
    Feb 21, 2016 at 7:04
  • as @Rui F Ribeiro pointed out parameter 2 is possibly an option. Feb 21, 2016 at 22:44

I'm afraid all commands are run as the build user.

Then anybody who submits a build can see, and even interfere, with the jobs of another user. Running a build can execute arbitrary code; this allows anybody who submits a build not only to run ps but also to read and write files belonging to other jobs. If you can't trust the users who submit builds then you must run the builds as separate users.

If you're concerned only with users who have an account on that CI server but aren't allowed to submit builds, then the hidepid option may help you. Alternatively, educate build submitters to pass confidential information in files or environment variables instead of command line arguments. Note that the ps command isn't what you need to take care of, it's just a pretty-printer for information found in the proc filesystem. The command line of process 1234 can be printed with cat /proc/1234/cmdline.

If you have confidentiality concerns with builds, I recommend that rather than attempting to plug one potential information leak at a time, you run all builds in a container or virtual machine.


Rather than passing information on the command-line, you could modify your program to read the information on its standard input, and run it via a subprocess that starts it with popen (a pipe). Just be sure to close the pipe with pclose when you are done.

Further reading:

  • 1
    Thanks for the answe but since this is a CI server with many users, it would not be practical to impose this guardrail. Feb 21, 2016 at 22:45

You must log in to answer this question.

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