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

Kevin Darcy kcd at daimlerchrysler.com
Wed Mar 28 01:42:14 UTC 2001


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. (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





More information about the bind-users mailing list