<div dir="ltr">Yes, I saw that. I don't have experience with low-level socket programming, so I can see this<div>is more of a project than I want to try - unless I could find a complete example of how this works.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 8, 2013 at 12:20 PM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 07/03/2013 07:43 PM, Pavel Emelyanov wrote:<br>
> On 07/03/2013 06:34 PM, Neal Becker wrote:<br>
>> How can the daemon reliably know what is the PID of the requesting process (and that<br>
>> it's not some evil program requesting a dump of some other process)?<br>
><br>
><br>
> Oh, I believe we can do a very beautiful thing here. On kernels which crtools support<br>
> there's a way to find peers of unix sockets. So, the "dump me" request would look like<br>
> this:<br>
><br>
> 1. app creates a unix socket and connects to server (by some known path/name)<br>
> 2. criu service finds out the peer of the accepted connection and dumps _it_<br>
><br>
> In this scheme we don't even need to pass any PIDs over the socket!<br>
<br>
</div></div>I've found an easier way of doing the same. There's a nice sockoption called<br>
SO_PEERCREDS. When called on a connected unix socket it reports back the peer's<br>
pid, uid and gid. Thus we can find out the pid easily.<br>
<br>
> Thanks,<br>
> Pavel<br>
><br>
<br>
Thanks,<br>
Pavel<br>
</blockquote></div><br></div>