Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!news-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Newsgroups: comp.os.linux.development.system
Subject: Re: "Permission denied" while reading file /proc/<pid>/maps with permissions '-r--r--r--'
Date: Tue, 16 Jul 2013 13:06:14 +0100
Lines: 32
Message-ID: <87k3kqk8uh.fsf@sapphire.mobileactivedefense.com>
References: <20de89c1-dcb3-42b2-b281-d22af2035db5@googlegroups.com> <5f18d1b7-791f-449a-8643-0c88267d107b@googlegroups.com> <87wqosgpmi.fsf@araminta.anjou.terraraq.org.uk> <ks0gc4$fiu$1@dont-email.me> <87r4f0gllc.fsf@araminta.anjou.terraraq.org.uk> <ks34ll$pr2$1@dont-email.me> <8738rekdbw.fsf@araminta.anjou.terraraq.org.uk> <ks38b5$aqa$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net Bmb3HbTAEHRtKNIP8ePdVwzjT5p0RZca1v8iw3igB2vjeWR7g=
Cancel-Lock: sha1:V84NsVIpvIlrhxX57EzSVBlDHuw= sha1:PKE62zCT3IVxPNZoVUWVRPKMbZw=
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Xref: csiph.com comp.os.linux.development.system:512

crankypuss <crankypuss@nomail.invalid> writes:
> On 07/16/2013 04:29 AM, Richard Kettlewell wrote:

[...]

>>> Pardon my attitude, but that is ridiculous.  Either the function
>>> should work 100%, it should be fixed, or it should be removed.
>>> Granted the timing issues involved with this kind of thing are legion,
>>> but that is one of the reasons for the concept of locking.  I get the
>>> idea from other comments in the documentation that the presence of
>>> access in linux is motivated politically rather than technically, that
>>> it's part of the requirements for a posix certification or something.
>>
>> The problem the warning refers to is a privileged program (for instance,
>> a setuid program) checking the access rights of an unprivileged user to
>> a path that the unprivileged user can control some element of.
>>
>> If the checking program isn’t privileged relative to the calling user,
>> or if it’s checking for access to some path that cannot be controlled by
>> an unprivileged user, then the warning isn’t really relevant.
>
> If the guy is running as root, all bets are off to begin with.

This is supposed to setuid processes which run with an effective user
id (euid) different from their real user id. The permission check
performed by access uses the real uid and this means it seems as if
this was a way the program running with a different euid could check
whether or not the user who invoked it has permission to access a
certain filesystem object. But this doesn't work reliably because the
same path name could refer to a different filesystem object by the
time the actual 'access routine' (usually, open) runs or the
permissions of the checked filesystem object could change in between.