Bug 1186922

This is an interesting problem since this library is on the host but mounted under /host/lib64/libwrap.so.0

I wonder if we could fix this by adding something like

export LD_LIBRARY_PATH=/usr/lib64:/host/usr/lib64

Then executing the command?

Why would ltrace inside the container not be able to ltrace processes running within the container?  It has all the shared libraries necessary.

The container is not going to know the ID of itself. at lest for now.

Did you try with the LD_LIBRARY_PATH suggested above?

It sounds like ltrace needs updating to flip into the container's mount namespace before opening the files.  If ltrace is single-threaded then this is easy:

Setup:
  struct stat sb;

  ltrace_mnt_ns_fd = open("/proc/%d/ns/mnt" % getpid(), O_RDONLY); // this can persist until ltrace exits
  traced_mnt_ns_fd = open("/proc/%d/ns/mnt" % PID_OF_TRACED_PROCESS, O_RDONLY);  // this can persist until traced process exits

  fstat (ltrace_mnt_ns_fd, &sb)
  ltrace_mnt_ns_id = sb.st_ino

  fstat (traced_mnt_ns_fd, &sb)
  traced_mnt_ns_id = sb.st_ino

  setns_needed = (ltrace_mnt_ns_id != traced_mnt_ns_id)


To open a file:
  if (setns_needed)
    setns (traced_mnt_ns_fd, 0);
  fd = open ("/lib64/libwrap.so.0", ...)
  if (setns_needed)
    setns (ltrace_mnt_ns_fd);

Obviously you have to check for errors.  You don't need to flip for read, write, fstat, or anything else that takes a file descriptor argument.

setns requires some capabilities, which is why it's wrapped: if they're in the same namespace you don't need the setns and thus don't need the capabilities.  If they're in different namespaces then setns will fail with EPERM or some such thing.  (i.e.,

You could just stay in the traced process's namespace but this causes problems if the parent process hasn't completely loaded all its own libraries--it has no access to its own filesystem.  I don't believe there's any way to check this so I think it's safer to dip in and out of the child's mount namespace as necessary.

If ltrace is multithreaded then you will have to spawn a single-threaded helper to handle the namespace flips.  GDB does this, it's all in 
nat/linux-namespaces.c.  It's harder but doable.

If ltrace respects LD_LIBRARY_PATH you *might* be able to work around this issue with LD_LIBRARY_PATH=/proc/$PID_OF_TRACED_PROCESS/root but if anything tries to process symlinks it will break.  There's no way around that that isn't racy and insecure, so this is at best a workaround; the only robust solution is entering the namespace.

*** Bug 1249835 has been marked as a duplicate of this bug. ***

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.