From: Daryl Tester <dt-lkml@handcraftedcomputers.com.au>
To: Sven Wegener <sven.wegener@stealer.net>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Re: PROBLEM?: "permission denied" when accessing /proc/self/fd/* after setuid
Date: Fri, 08 Aug 2008 10:08:21 +0930 [thread overview]
Message-ID: <489B957D.9080206@handcraftedcomputers.com.au> (raw)
In-Reply-To: <alpine.LNX.1.10.0808071311300.16201@titan.stealer.net>
Sven Wegener wrote:
> If a program wants to fiddle with an existing _file_descriptor_, it should
> use the dup syscalls or access the descriptor directly.
If you have the source to the program, and can (and are allow to) modify
it, then yes I agree, but that isn't always an option. And I guess why
have the interface in the first place if we have dup() and friends?.
> Don't know if the behaviour of /dev/std* and /proc/self/fd/* is
> standardized in some way. But I guess it's implementation-specific.
I guess that's something I was after - if this behavior was defined.
My *belief* (which is questionable) is that it was to emulate dup()
behavior, which it obviously isn't in this case.
>> The above environment isn't necessary to replicate the problem, although
>> what stdout and stderr are attached to has some effect. The attached C
>> code replicates the issue, but appears to not fail (that is, succeed) if
>> /proc/self/fd/2 is a terminal (e.g. /dev/pts/X) *and* that terminal is
>> owned by the same uid that the code uses (in this case, 500). In the
>> case of an anonymous pipe it appears to fail consistently as the pipe is
>> owned by root.
> Why should it fail for the terminal? You're the owner of it.
I didn't expect it to fail, but then I didn't expect it to fail under any
condition. That it's failing for the other conditions is my beef. :-)
> Don't have a FreeBSD installation at my fingers, so can't verify. Maybe
> they just don't use symlinks to represent the open files, so they do not
> end up opening the original file.
According to the man page on my crufty 4.11 box:
If the file descriptor is open and the mode the file is being opened
with is a subset of the mode of the existing descriptor, the call:
fd = open("/dev/fd/0", mode);
and the call:
fd = fcntl(0, F_DUPFD, 0);
are equivalent.
I don't have a more recent box handy, but the man page at
<http://www.freebsd.org/cgi/man.cgi?query=stderr&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html>
infers that this is still the case.
> As said above, don't know if the behaviour is standardized.
Anybody? Bueller?
Thanks for the response; they warned me this was a high traffic list. :-)
Cheers,
--dt
next prev parent reply other threads:[~2008-08-08 0:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-07 6:16 PROBLEM?: "permission denied" when accessing /proc/self/fd/* after setuid Daryl Tester
2008-08-07 15:20 ` Sven Wegener
2008-08-08 0:38 ` Daryl Tester [this message]
2008-08-08 0:50 ` Alexey Dobriyan
2008-08-08 2:24 ` Daryl Tester
2008-08-08 2:59 ` Daryl Tester
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=489B957D.9080206@handcraftedcomputers.com.au \
--to=dt-lkml@handcraftedcomputers.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=sven.wegener@stealer.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.