 <p>It's because the file permissions are not the only protection you're encountering.</p> <p>Those aren't just regular text files on a file system, <code>procfs</code> is a window into process internals and you have to get past both the file permissions <em>plus</em> whatever other protections are in place.</p> <p>The maps show potentially dangerous information about memory usage and where executable code is located within the process space. If you look into ASLR, you'll see this was a method of preventing potential attackers from knowing where code was loaded and it wouldn't make sense to reveal it in a world-readable entry in <code>procfs</code>.</p> <p>This protection was added <a href="http://lwn.net/Articles/225589/">way back in 2007</a>:</p> <blockquote> <p>This change implements a check using "ptrace_may_attach" before allowing access to read the maps contents. To control this protection, the new knob /proc/sys/kernel/maps_protect has been added, with corresponding updates to the procfs documentation.</p> </blockquote> <p>Within <code>ptrace_may_attach()</code> (actually within one of the functions it calls) lies the following code:</p> <pre><code>if (((current-&gt;uid != task-&gt;euid) || (current-&gt;uid != task-&gt;suid) || (current-&gt;uid != task-&gt;uid) || (current-&gt;gid != task-&gt;egid) || (current-&gt;gid != task-&gt;sgid) || (current-&gt;gid != task-&gt;gid)) &amp;&amp; !capable(CAP_SYS_PTRACE)) return -EPERM; </code></pre> <p>so that, unless you have the same real user/group ID, saved user/group ID and effective user/group ID (i.e., no sneaky <code>setuid</code> stuff) and they're the same as the user/group ID that owns the process, you're not allowed to see inside that "file" (unless your process has the <code>CAP_SYS_PTRACE</code> capability of course).</p>