I am just answering another question here :-) and thus had a look – wanted to have a look at /proc/$PID/fd of ssh-agent in order to find out which socket it uses. But I can't. I am quite surprised to notice that most files and directories belong to root. ssh-agent runs as my user (so does its parent process) and is not installed SUID root. I wasn't able to find out where exactly KDE starts it. I am curious; can someone tell my what's happening here?

Or is this not about the user at all, can processes use some kernel magic in order to hide (most of) their /proc info from the public (and even other processes of the same user)?

I just checked the /proc/$PID/fd of all my processes and noticed that ssh-agent is not the only process with this strange attribute. The others are the bunch of Chrome processes and kdesud (no SUID root binary either).

  • What Linux distro is this?
    – slm
    May 8, 2013 at 2:54
  • @slm openSUSE 12.2 May 8, 2013 at 15:11
  • I think @msw's answer is the reason. What do you think?
    – slm
    May 8, 2013 at 15:26
  • @slm No, it's not. See my comment there. May 8, 2013 at 17:52
  • 2
    Since that's not it here's what I was thinking lastnight before I saw @msw's answer. Perhaps it's this: chromium.org/chromium-os/chromiumos-design-docs/…. On that page they discuss cgroups, which seems to be what's going on with Chrome anyway.
    – slm
    May 8, 2013 at 18:09

4 Answers 4


[The following is adapted from text I'm just in the process of adding to the proc(5) manual page, which answers this question.]

The files under /proc/PID are normally owned by the effective user and effective group ID of the process. However, as a security measure, the ownership is made root:root if the process's "dumpable" attribute is set to a value other than 1. [The default value of this attribute is 1. Setting this attribute to 0 causes a process not to produce core dumps, since they may contain sensitive information. Likewise, certain files in /proc/PID can provide access to sensitive information.]

This attribute may change for the following reasons:

  1. The attribute was explicitly set via the prctl(2) PR_SET_DUMPABLE operation.
  2. The attribute was reset to the value in the file /proc/sys/fs/suid_dumpable.

The default value in /proc/sys/fs/suid_dumpable is 0. The reasons that the dumpable attribute may be reset to the value in the suid_dumpable file are described in the prctl(2) manual page:

  • The process's effective user or group ID is changed.
  • The process's filesystem user or group ID is changed.
  • The process executes a set-user-ID or set-group-ID program, or a program that has capabilities.

For chrome the reason is that chrome-sandbox has the suid bit so it runs with root privileges.

Regarding your issue with ssh-agent I am not sure though in my case /usr/bin/ssh-agent has a suid bit set, i.e. the root entries make sense. I don't know how kde handles the ssh-agent but I am pretty sure there is an suid helper involved.

In general there are no magic things, typically a program has to either have a suid bit, explicitly specified the CAPABILITIES or utilize some kind of external helper, either via directly executing it or something like polkit.

As these programs run as root, but dropped then their privileges, you see them running as your user in ps but files are still owned by suid bit owner.


Your display manager (lightdm, openbox, etc.) is a child of init which is owned by root. Init isn't set-uid because it's a very special process and is just started with uid of 0. The command ps -eaH gives a structured view of parentage, the relevant bits are:

r    1 ?        00:00:00 init
r 1521 ?        00:00:00   lightdm
r 1531 tty7     00:00:12     Xorg
m 2035 ?        00:00:00     lightdm
m 2177 ?        00:00:00       gnome-session
m 2225 ?        00:00:00         ssh-agent

Where I prepended the owner (Root or Me) of the process. Remember that /proc isn't a real filesystem, but provides file-like access into internal kernel structures and the kernel can set whatever permissions deemed appropriate. Even though 2035 has a real and effective UID of me, the entries in /proc/2035 are owned by root and /proc/2035/fd has permissions 0700 (-r-x------). It isn't until we get to 2177 that I own the pseudo-files in proc because the PPID of 2177 was not UID root.

Why? Because if I was spawned by a root program, some of my files might allow me to leverage into system security. This used to be otherwise as the proc(5) man notes under /proc/sys/fs/protected_hardlinks:

The default value in this file is 0. Setting the value to 1 prevents a longstanding class of security issues caused by hard- link-based time-of-check, time-of-use races, most commonly seen in world-writable directories such as /tmp. The common method of exploiting this flaw is to cross privilege boundaries when following a given hard link (i.e., a root process follows a hard link created by another user). Additionally, on systems without separated partitions, this stops unauthorized users from "pinning" vulnerable set-user-ID and set-group-ID files against being upgraded by the administrator, or linking to special files.

While this note doesn't speak exactly to why the /proc/fd attack vector can be exploited, it does give the feel better than a few thousand lines of code from kernel/fs/proc.

  • This is not the correct answer. The session start programs are not called as root. That would be insane from a security perspective. So ssh-agent is not started as root, too. Chrome is not even related to the session start processes. I just checked with sudo: If a process changes its (E)UID then the files in /proc/$PID adapt their owner. All of them. In my case most but not all files (and directories) belong to root. May 8, 2013 at 17:52
  • I didn't say they were called as root. I said they inherited their real, effective, saved set, and file system UIDs from the parent. Indeed, until the display manager asks who you are, it can't rightly assign any owner to the process. As I showed above Xorg runs with UID 0, check it out in /proc/n/status. As I also showed above, its subordinate processes run as me. As far as your chrome goes, mine runs as me; what's screwed up with your installation?
    – msw
    May 8, 2013 at 20:26
  • What makes you think my installation was screwed up? Chrome does not run as root here but most of its /proc/$PID content is owned by root. I just noticed that this is not even true for the two first Chrome processes but only for chrome-sandbox and its children. May 8, 2013 at 20:32
  • 1
    hardlink protection has nothing to do with the described issue. Jun 3, 2013 at 1:18

/proc is a special pseudo filesystem. From proc(5) (man 5 proc):

   The proc file system is a pseudo-file system which is used as an inter-
   face to kernel data structures.  It is commonly mounted at /proc.  Most
   of  it  is  read-only,  but  some  files  allow  kernel variables to be

I recommend reading the complete man page for an explanation.

You must log in to answer this question.

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