>> As a non-root user:
>>
>> a. I can't do readlink() on /proc/1/exe ("ls -l /proc/1/exe")
>> b. I can do "cat /proc/1/maps" to see what files are mapped
>>
>> That's backwards. If a user can read /proc/1/cmdline, then
>> they might as well be permitted to readlink() on /proc/1/exe
>> as well. Reading /proc/1/maps is quite another matter,
>> exposing more info than the (prohibited) /proc/1/fd/* does.
>
> It seems to have been this way since at least 2.2. It isn't
> exclusive to the /proc/*/exe. It applies to all symlinks in
> /proc/$pid.
Guessing:
1. readlink and follow permissions were not distinct
2. symlink following in /proc wasn't done normally
3. therefore, readlink implied access to the target's data
Rather than fix #1 or #2, readlink() got restricted.
> As near as i can tell it seems to be a
> functional-equivalency carryover from 2.2. It isn't causing
> much harm but i do wonder if this is intentional and if so,
> why. I'm at a loss to see why refusing to allow non-owners
> to identify a process's cwd, exe, and root would be
> desireable. The only other things we refuse are mem, fd/
> and eviron, the reasons for which are obvious and the
> restrictions are per-file rather than as a class.
Being able to readlink() in the fd directory is much less
revealing than the content of the maps file. IMHO both of
them should be restricted, but the "maps" file matters more.
Just look at this: cat /proc/1/maps
This all looks completely mixed up. Users SHOULD NOT be able
to read /proc/1/maps, but SHOULD be able to readlink at least
any /proc/1/* symlink that has meaning in the current namespace.
(so not if the observer is in a chroot environment)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/