Re: [PATCH 8/9 v2] Implement vFile:setfs in gdbserver

[Gary Benson <gbenson@redhat.com>]

Gary Benson wrote:
> Pedro Alves wrote:
> > On 06/09/2015 03:11 PM, Gary Benson wrote:
> > > Pedro Alves wrote:
> > > > For the setns/ENOSYS case, how about somehow probing whether
> > > > setns actually works here (with a new method, or probing one
> > > > of the existing ones with getpid()) and return empty packet,
> > > > instead of ending up with open failing with ENOSYS later on?
> > > 
> > > Probing and then telling GDB we don't understand "vFile:setfs:"
> > > isn't that good of an idea.  If we do that with an inferior in
> > > another mount namespace then the end result is that gdbserver will
> > > access the wrong filesystem.  You might get "file not found", or
> > > you might get an open filehandle on another file (i.e. the file
> > > with the same name but in gdbserver's filesystem).  If the
> > > inferior's filesystem is different from gdbserver and gdbserver
> > > cannot access that filesystem then the only correct response is
> > > to fail.
> > 
> > If the running system does not support "setfs", because it fails
> > setns with ENOSYS, meaning, the system call isn't implemented at
> > all, how can one end up in the situation that an inferior on the
> > same kernel is running in a different filesystem namespace?
> 
> If the running kernel has namespaces support but GDB and/or glibc
> was built on a kernel without.  It's an edge case but it's possible.

Note that GDB/gdbserver will not attempt to call setns unless the
inferior is actually in a different mount namespace.  If you're
running without namespaces support it won't even start the helper
let alone try to setns.  Same goes for if you have namespaces
support but the inferior is in GDB/gdbserver's mount namespace.
Nothing calls setns unless it is 100% necessary.

Cheers,
Gary

-- 
http://gbenson.net/