Connecting to an "abstract" socket from Java

[Jon]

Background:

We have a service that creates a chroot-ed Linux environment, sharing
the Linux kernel with Android. I have a daemon that runs in this
chroot-ed environment that creates an AF_UNIX socket. I originally
coded this to bind() to a filename in /tmp, and all was well; the
Android client simply created a LocalSocketAddress in the FILESYSTEM
namespace, prepending the chroot path to the socket name that the
daemon bound.

I've been asked to remove this dependency on the chroot path, so that
the service can be relocated without having to change my daemon and
its Android client. No problem, says I, I'll just move it to the
ABSTRACT namespace, and we'll be a bit more secure, too.

But! I get a "Connection refused" IOException when I try to connect to
the abstract socket, whether I use "'\0' + path" or just "path", and
whether I use "new LocalSocketAddress(path)" or "new
LocalSocketAddress(path, LocalSocketAddress.Namespace.ABSTRACT)".

I've tried changing my daemon's bind() call to pass "(char*)
(&addr.sun_path) - (char*)(&addr) + 1 + strlen(SOCKET_PATH) + 1"
instead of "sizeof(addr)", and that makes no difference.

Question(s):

Is there some magic involved in connecting to non-Java abstract
sockets? Is there maybe a code sample somewhere that I missed in my
Googling?

[Jon]

Experiments with getsockname() revealed that I need to pass
"strlen(SOCKET_PATH) + 1" to bind() (to get the equivalent of {'\0',
'S', 'O', 'C', 'K', 'E', 'T', '_', 'P', 'A', 'T', 'H',} ) ... but I
still can't connect to my abstract socket from my Android client.

Android issue? Or can FILESYSTEM local sockets cross the chroot
barrier in a way that ABTRACT sockets can't?

[Chris Stratton]

On Dec 14, 8:42 pm, Jon <shem...@gmail.com> wrote:

> > I've been asked to remove this dependency on the chroot path, so that
> > the service can be relocated without having to change my daemon and
> > its Android client. No problem, says I, I'll just move it to the
> > ABSTRACT namespace, and we'll be a bit more secure, too.

I don't know the specific answer to your problem, but I'd be tempted
to see if I could figure out if it was an abstract socket usage
problem, a chroot side effect, or an android-isn't-quite-linux
problem. Some ideas:

a) Try the abstract socket without the chroot and make sure that at
least works

b) Try the abstract socket with the chroot on an ordinary desktop (non-
android) linux and see if it works there.

[Jon Shemitz]

Thanks, Chris, good ideas. (I thought of similar things yesterday, but
wanted to try the 'less scaffolding' approaches, first.)

But I think we're going to go with a simpler idea that I had last
night: The script that sets up the service will just write the chroot
path to a file, and my client can then read that at connect time. So,
we eliminate the dependency on a known path; keep the working local
socket code; and avoid the time sinks of getting abstract sockets to
work or switching to IF_INET sockets, which are less efficient and
which add security risk.