From: Bruno Haible <bruno@clisp.org>
To: David Daney <david.daney@cavium.com>
Cc: "bug-gnulib@gnu.org" <bug-gnulib@gnu.org>,
"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: bug in fchownat in n32 and 64 ABIs
Date: Fri, 28 Oct 2011 01:59:41 +0200 [thread overview]
Message-ID: <201110280159.41533.bruno@clisp.org> (raw)
In-Reply-To: <4EA9B072.5000107@cavium.com>
David Daney wrote:
> > 'strace' of this program shows that the system call that returns with -1/EPERM
> > is a call to SYS_6254 (in n32 ABI) or SYS_5250 (in 64 ABI).
> >
> Can you get strace -- version 4.5.20 or later and build it for the
> corresponding ABI? That should properly decode the relevant syscalls.
Version 4.6, built with "gcc -m64", compared to version 4.5.17:
For the program in ABI 64:
strace 4.5.17 reports
SYS_5250() = -1 EPERM (Operation not permitted)
strace 4.6 reports nothing, it stopped the log after it saw an exit() call:
getsockopt(1099511620912, 0xfffff820 /* SOL_??? */, 1099511625776, 0, 0x5555748ed0) = 0
svr4_syscall() = 5012
exit(1099511623472) = ?
fchownat: Operation not permitted
fchownat: Operation not permitted
fchownat: Operation not permitted
For the program in ABI n32:
strace 4.5.17 reports
SYS_6254() = -1 EPERM (Operation not permitted)
strace 4.6 reports
n32_inotify_add_watch(0xffffffffffffff9c, 0x10000a30, 0xffffffff) = -1 EPERM (Operation not permitted)
n32_inotify_add_watch(0xffffffffffffff9c, 0x10000a30, 0x4f0) = -1 EPERM (Operation not permitted)
n32_inotify_add_watch(0xffffffffffffff9c, 0x10000a30, 0xffffffff) = -1 EPERM (Operation not permitted)
For the program in ABI 32:
strace 4.5.17 reports
fchownat(AT_FDCWD, "foo.c", -1, 1264, 0) = 0
fchownat(AT_FDCWD, "foo.c", 1264, -1, 0) = 0
fchownat(AT_FDCWD, "foo.c", -1, -1, 0) = 0
strace 4.6 reports
o32_fchownat(0xffffffffffffff9c, 0x400b00, 0xffffffffffffffff, 0x4f0, 0) = 0
o32_fchownat(0xffffffffffffff9c, 0x400b00, 0x4f0, 0xffffffffffffffff, 0) = 0
o32_fchownat(0xffffffffffffff9c, 0x400b00, 0xffffffffffffffff, 0xffffffffffffffff, 0) = 0
These traces reveal that
- in ABI 32 (the case that works) the value (uid_t)-1 is being passed
to the kernel as 0xffffffffffffffff,
- in ABI n32 (the case that fails) the value (uid_t)-1 is being passed
to the kernel as 0x00000000ffffffff.
Note that 'uid_t' is 'unsigned int' in userland.
Bruno
--
In memoriam Helmuth Hübener <http://en.wikipedia.org/wiki/Helmuth_Hübener>
next prev parent reply other threads:[~2011-10-27 23:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-27 19:07 bug in fchownat in n32 and 64 ABIs Bruno Haible
2011-10-27 19:26 ` David Daney
2011-10-27 21:29 ` David Daney
2011-10-27 23:59 ` Bruno Haible [this message]
2011-10-28 0:26 ` David Daney
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=201110280159.41533.bruno@clisp.org \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=david.daney@cavium.com \
--cc=linux-mips@linux-mips.org \
/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