mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®