can't exec /usr/sbin/named-xfer: Permission denied

[Brian Elliott Finley]

Thus spake Kevin Darcy (kcd at daimlerchrysler.com):

> 
> Well, this is starting to look like a real stumper. You've already checked the existence, ownership and permissions of named-xfer within the chroot jail, and you can run it manually while chroot()'ed as the unprivileged ID, yet execve() is clearly getting EACCES. Baffling.

:)

> If it were me, at this point I'd probably replace "/usr/sbin/named-xfer" with a wrapper program that would stat() the real executable and write the results to a file, before attempting to execve() it. If named fails to run the wrapper program, that tells you there's something funky about how
> named is fork()'ing/exec()'ing named-xfer. If named *does* run the wrapper program, which then fails to execve() the real executable, at least you have all of the stat() information available for analysis, as a double-check that the ownership and permissions are what you think they are. If
> everything works, then just leave the wrapper program in place and forget about it. 

Interesting idea...  As I said before, I would really like to take this
to it's bloody end -- I'm sure there are others having the same issue.

> (Only kidding :-)
> 
> Ultimately, this might turn out to be some kind of kernel bug. But I am far from leaping to such a conclusion at this stage...
> 
>                                                                                                                 - Kevin
> 
> Brian Elliott Finley wrote:
> 
> > Thus spake Kevin Darcy (kcd at daimlerchrysler.com):
> >
> > >
> > > Brian Elliott Finley wrote:
> > >
> > > > Thus spake Kevin Darcy (kcd at daimlerchrysler.com):
> > > >
> > > > >
> > > > > Linux has a system-call tracer, doesn't it? "strace" or something like that? Fire that up to
> > > > > determine *exactly* what named is trying to execute.
> > > >
> > > > I have run it (and named-xfer) successfully by hand.  The problem is
> > > > trying to get named to invoke strace when it automatically invokes
> > > > named-xfer.
> > >
> > > Doesn't strace have a "follow" option, like Solaris truss'es "-f" option, i.e. follow child
> > > processes?
> >
> > Yes.  Below is the output from:
> > "strace -f -F -o/tmp/strace /usr/sbin/named -u bind -g bind -t /chrootd/bind"
> >
> > <<< relevant output -- one long line >>>
> > 19847 execve("/usr/sbin/named-xfer", ["/usr/sbin/named-xfer", "-z", "nylug.org", "-f", "/var/cache/bind/db.nylug.org", "-i", "/var/cache/bind/db.nylug.org.ixf"..., "-C", "1", "-P", "13568", "-T", "nylug.org.19558", "12.33.122.126", "axfr"], [/* 19 vars */]) = -1 EACCES (Permission denied)
> >
> > > By the way, you indicated that you're running an exploitable version (8.2.2-p7).
> >
> > I've gone ahead and upgraded.  Still having this problem, though.
> >
> > Thanks for everyone's help, by the way...
> >
> > -Brian
> 
> 
> 

-- 
-------------------------------------------------------
 Brian Elliott Finley     VA Linux http://valinux.com/
 http://thefinleys.com/            phone: 972.447.9563
 http://systemimager.org/           phax: 801.912.6057
 CSA, C2000, CNE, CLSE, MCP, and Certifiable Linux Nut
-------------------------------------------------------