Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm running a Debian server and giving out shell access for a handful of friends. I'd like to hide the running processes from those normal users, so that for example top only shows their own processes, and not anything started by anyone else. Obviously root should see all processes, though.

How would I do this? I've seen it in action on many shared hosting services that offer shell accounts, but haven't come across a way to do it myself.

share|improve this question
up vote 4 down vote accepted

Only with Linux is not possible. With SeLinux or GrSecurity you can "hide"(in fact, you don't give it access) processes between users. It's a little bit complicated, but not impossible.

share|improve this answer

A quick and easy way for top, but not bullet-proof, is to give them an alias in their ~/.bashrc (or the shell-specific appropriate startup/alias file) that just runs top looking at their own username:

alias top="top -u $USER"

This doesn't do anything for ps or course, but aside from putting users in a chroot or jail environment, or selinux as Sacx mentioned, there's not a lot that you can do to hide the system from them.

share|improve this answer

There is the command line option -U

Monitor by user as: -U somebody Monitor only processes with a UID or user name matching that given. This matches real, effective, saved, and filesystem UIDs.

or -u

Monitor by user as: -u somebody Monitor only processes with an effective UID or user name matching that given.

How you would effectively enforce this on users who have command line access I don't really know. Given that users have access to the command line they could use a variety of other tools to see other peoples processes anyway.

share|improve this answer

If you aren't interested in SELinux, you could possibly get some traction with this problem by getting creative with permissions on the PID subdirectories in /proc/, but some massive testing would have to be done.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.