On Mon, Oct 14, 2013 at 3:45 AM, Daniel P. Berrange <berra...@redhat.com> wrote:
> On Sun, Oct 13, 2013 at 11:08:09AM -0500, Doug Goldstein wrote:
>> While LOCAL_PEERCRED on the BSDs does not return the pid information of
>> the peer, Mac OS X 10.8 added LOCAL_PEERPID to retrieve the pid so we
>> should use that when its available to get that information.
>> ---
>> v2:
>> * Make LOCAL_PEERPID call non-fatal in case the user built the binary on
>>   a system that supports it but then runs it on a kernel that does not
>>   support it
>> ---
>>  src/rpc/virnetsocket.c | 19 ++++++++++++++++++-
>>  1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c
>> index e8cdfa6..7126c4f 100644
>> --- a/src/rpc/virnetsocket.c
>> +++ b/src/rpc/virnetsocket.c
>> @@ -1195,12 +1195,29 @@ int virNetSocketGetUNIXIdentity(virNetSocketPtr sock,
>>          return -1;
>>      }
>>
>> -    /* PID and process creation time are not supported on BSDs */
>> +    /* PID and process creation time are not supported on BSDs by
>> +     * LOCAL_PEERCRED.
>> +     */
>>      *pid = -1;
>>      *timestamp = -1;
>>      *uid = cr.cr_uid;
>>      *gid = cr.cr_gid;
>>
>> +# ifdef LOCAL_PEERPID
>> +    /* Exists on Mac OS X 10.8 for retrieving the peer's PID */
>> +    cr_len = sizeof(*pid);
>> +
>> +    if (getsockopt(sock->fd, VIR_SOL_PEERCRED, LOCAL_PEERPID, pid, &cr_len) 
>> < 0) {
>> +        virReportSystemError(errno, "%s",
>> +                             _("Failed to get client socket PID"));
>> +        /* Don't treat this as fatal, but do set the value to something sane
>> +         * in case the user built this on a system that has LOCAL_PEERPID
>> +         * defined but the kernel does not actually support it.
>> +         */
>> +        *pid = -1;
>
> You shouldn't call virReportSystemError if you're going to ignore the
> error. I don't think we want to blindly ignore all errors though. Can
> you find out what error older OS-X gives with this unsupported value
> and just check for that. I'm guessing it'd probably be EINVAL.
>
>
> Daniel

Can do.

-- 
Doug Goldstein

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to