Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unix domain socket filepaths should be translated #8

Closed
hhm0 opened this issue Feb 21, 2013 · 15 comments
Closed

unix domain socket filepaths should be translated #8

hhm0 opened this issue Feb 21, 2013 · 15 comments
Assignees

Comments

@hhm0
Copy link

hhm0 commented Feb 21, 2013

Currently, paths for Unix domain sockets are not being translated to target paths..

This can prevent programs which depend on them to fail (which can cause filesystem errors which may not make sense to a user), or to need customized settings (e.g. tmux -S ./tmp/tmux, without / at beginning of filepath).

I think the fix would be to detect the bind system call when sockaddr.sun_family equals AF_UNIX, and then translate sockaddr.sun_path to a target filepath when it is found.

This came up while trying to use tmux on tal-dew on an Android phone. tmux tries to make a unix domain socket in /tmp, a directory Android does not have (in version 2.3 which I tested on).

@cedric-vincent
Copy link
Contributor

Nice catch! I'm looking at this problem.

@hhm0
Copy link
Author

hhm0 commented Feb 21, 2013

Thank you! :-)

On Thu, Feb 21, 2013 at 3:28 AM, Cédric VINCENT notifications@github.comwrote:

Nice catch! I'm looking at this problem.


Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-13878088.

@ghost ghost assigned cedric-vincent Feb 21, 2013
@cedric-vincent
Copy link
Contributor

Commit 2001f0d should fix this problem.

@cedric-vincent
Copy link
Contributor

Oops, the related test-case fails on Ubuntu: https://travis-ci.org/cedric-vincent/PRoot/builds/5039014/#L117

@cedric-vincent
Copy link
Contributor

It works on Ubuntu locally. Maybe the problem is due to the Travis sandboxing: https://travis-ci.org/cedric-vincent/PRoot/builds/5039412/#L2729

@cedric-vincent
Copy link
Contributor

I forgot to handle socketcall(2) too.

@cedric-vincent
Copy link
Contributor

commit da92b78 fixes a critical bug in the previous implementation. I checked it now works with tmux on x86_64. Support for socketcall(2) and sendto(2) is still missing.

@cedric-vincent
Copy link
Contributor

Hello @hhm0

Do you confirm the release v2.4.1 works as expected in this regard?

Regards,
Cedric.

@hhm0
Copy link
Author

hhm0 commented Apr 10, 2013

For tmux, and for socat using unix/unix-listen or
unix-sendto/unix-recv[from] it works fine, for
dtachhttp://dtach.sourceforge.net/ it
doesn't work. (doesnt show a terminal, just blank screen and keys not
working, detach key works ok though, detaching it.

Thanks for the fixes sofar! Awesome work! :-)

On Tue, Apr 9, 2013 at 4:55 AM, Cédric VINCENT notifications@github.comwrote:

Hello @hhm0 https://github.com/hhm0

Do you confirm the release v2.4.1 works as expected in this regard?

Regards,
Cedric.


Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-16101330
.

@cedric-vincent
Copy link
Contributor

Many thanks for all these tests! I'm able to reproduce the problem with dtach. I'll keep you informed.

@cedric-vincent
Copy link
Contributor

As of my understanding, the issue with dtach under proot is due to the
fact that proot waits (for ptrace events) in the foreground, even if
all of its tracees were moved to the background. The problem is
reproducible with the code below: under proot, the terminal control is
never passed back to the parent shell, as it ought to be. In this
regard, proot is not transparent.

int main()
{
    daemon(0, 0);
    while (1)
        sleep(1);
    return 0;
}

I'll create a new entry for this issue.

Note: strace -f suffers the same issue.

@cedric-vincent
Copy link
Contributor

The problem with dtach was moved to issue #11, feel free to re-open this issue if Unix domain sockets doesn't work as expected.

Thanks for your bug/test reports!

AkihiroSuda pushed a commit to rootless-containers/runrootless that referenced this issue Jan 8, 2018
Change-Id: I0c2dab27efe9ee54e1f5fddd76f663dbc8eec797
Reported-By: <heehooman@gmail.com>
Ref: proot-me/proot#8
@pespin
Copy link

pespin commented Jan 11, 2018

Please, implement this for sendto() too. I have a test case which works without proot but fails with proot as of v5.1.0:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <fcntl.h>
#include <strings.h>

int main(int argc, char *argv[]) {

        char * socket_path = "foobarSocket";

        // create
        int mSocketFD = socket(AF_UNIX,SOCK_DGRAM,0);
        if (mSocketFD<0) {
                perror("socket() failed");
                exit(1);
        }

        // bind
        struct sockaddr_un address;
        size_t length = sizeof(address);
        bzero(&address,length);
        address.sun_family = AF_UNIX;
        strcpy(address.sun_path, socket_path);
        unlink(socket_path);
        if (bind(mSocketFD,(struct sockaddr*)&address,length) < 0) {
                perror("bind() failed");
                exit(1);
        }

        //send info, will fail withj proot:
        int retVal = sendto(mSocketFD, "foobar", strlen("foobar"), 0,
                (struct sockaddr *)&address, sizeof(struct sockaddr_un));
        if (retVal == -1 ) {
                perror("sendto()) failed");
                exit(1);
        }
        printf("OK");
        return retVal;
}

@jopasserat
Copy link
Member

Hi @pespin , thanks for reaching out!

Would you consider submitting a Pull Request?

@pespin
Copy link

pespin commented Jan 11, 2018

Sure, I'll do it whenever I have some time soon if nobody does it before me.

SvenDowideit pushed a commit to SvenDowideit/proot that referenced this issue Jan 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants