On 07/07/17 18:03, Sara Golemon wrote
>> The point is, regardless of unix - or tcp sockets, they still have an
>> underlying file descriptor, which I need to specify to the child, so
>> that they can start using it. Ergo, I need to find a way to export this
>> from the stream into PHP.
>>
> You misunderstand, I'm not saying to create a unix socket and try to
> pass that open pair to the child. I'm saying listen on a unix domain
> socket on the file system and tell the children what the path is.
> They can all individually then open streams to the parent using the
> path.
That would be an extremely ugly solution. You would create overhead for 1,
and 2, you leave open the possibility that an arbitrary application
(bound to the filesystem permissions) allows to connect to it during
the time the socket is listening.
See [0] for what can go wrong with a similar solutions.
>
> Psuedo code:
> // parent
> $mysocket = 'unix://tmp/parent.sock';
> $server = stream_socket_server($mysocket);
> spawn_child('child_proc --sock='.escapeshellarg($mysocket));
> $child = stream_socket_accept($server);
> var_dump(fgets($child)); // string (8) "Hi mom!\n"
>
> // child
> $parentssocket = parseCliArg('sock');
> $stream = stream_socket_client($parentssocket);
> fwrite($stream, "Hi mom!\n");
>
>
> Then the children can each report their own listening sockets to the
> parent and the parent can provide a lookup for siblings to find each
> other and allow them to open sockets to each other.
>
> Trying to pass a meaningless number to the child that it can't do
> anything with isn't going to work.
That's the whole point. They're not meaningless numbers, they're the
actual references that the kernel exposes to the process for file
access:
$ cd /tmp
$ cat test.php
<?php
$sp = stream_socket_pair(STREAM_PF_UNIX, STREAM_SOCK_STREAM, 0);
switch(pcntl_fork()) {
case -1:
exit(255);
case 0:
fclose($sp[1]);
// 3 is known because of known open files in default shell
pcntl_exec("/tmp/test", ["-i", "3"]);
default:
fclose($sp[0]);
fwrite($sp[1], "hello world");
}
?>
$ cat test.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int
main(int argc, char *argv[]) {
extern char *optarg;
int ch;
int fd = -1;
int readbytes;
char buf[sizeof("hello world")];
while ((ch = getopt(argc, argv, "i:")) != -1) {
switch(ch) {
case 'i':
fd = atoi(optarg);
break;
default:
fprintf(stderr, "wrong parameter\n");
exit(1);
}
}
readbytes = read(fd, buf, sizeof(buf));
buf[readbytes] = '\0';
printf("read: %s\n", buf);
}
$ gcc ./test.c -o test && php ./test.php
read: hello world
$ cat test.c
#include <errno.h>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/socket.h>
int
main(int argc, char *argv[]) {
int sp[2];
char *fd;
extern int errno;
socketpair(AF_UNIX, SOCK_STREAM, 0, sp);
switch(fork()) {
case -1:
exit(1);
case 0:
close(sp[1]);
asprintf(&fd, "%d", sp[0]);
execl("/usr/bin/env", "/usr/bin/env", "php", "/tmp/test2.php", "-i", fd, NULL);
default:
close(sp[0]);
write(sp[1], "hello world", sizeof("hello world"));
}
}
$ cat test2.php
<?php
$opts = getopt("i:");
$fd = null;
foreach ($opts as $opt => $arg) {
switch($opt) {
case "i":
$fd = fopen("php://fd/" . $arg, "r");
break;
default:
trigger_error("wrong parameter", E_USER_ERROR);
}
}
$buf = fread($fd, 11);
echo "read: " . $buf . "\n";
$ gcc ./test2.c -o ./test2 && ./test2
read: hello world
Don't mind the crummy C here, it's for illustration purposes only.
As you can see, these "meaningless numbers" allow me to connect two
applications written in two completely different languages without
setting up any external listening system.
The problem here is that for test.php I had to hardcode the value
3 because I don't know how to retrieve it from $sp[0]. This only
works in a default shell where only stdin, stdout and stderr
(fd0, fd1 and fd2) are set. The kernel allocates the next free fd,
which happens to have number 3.
As soon as I would execute it like:
php ./test.php < ./test.c
it would fail, because fd3 would be taken by a handle to test.c
and $sp[0] would be allocated on 4.
> -Sara
>
[0] https://legalhackers.com/videos/MySQL-MariaDB-PerconaDB-PrivEsc-Race-CVE-2016-6663-5616-6664-5617-Exploits.html
