[PATCH] server: Add an API to get the socket fd for a client

Sung-Jin Park input.hacker at gmail.com
Thu Jan 14 21:15:51 PST 2016


Dear guys and pq,
I updated the new version of patch with version 4 and modified its title to
the following. Sorry for my mistake. :D

"[PATCH v4] server: Add an API to get the file descriptor for a client" (
http://patchwork.freedesktop.org/patch/70475/)

Would you plz review it again whether it is better than before ? :)

Thanks and regards,
Sung-Jin Park

>sorry, that sounds completely bogus and I never implied anything like that.
Oh, don't mention it. I misunderstood your comment. :)
I'm also sorry for I mentioned UID in my previous email.
I think that sounds stranges. I should have mentioned PID instead of UID.

>socketpair() is used for creating a connection before fork()'ing and
>exec()'ing a client process, so that the process starts with an already
>open connection. In that case, wl_client_get_credentials() provides
>wrong information. Particularly the returned PID will be the
>compositor's, not the client's. I do not know if the security context
>you are interested in suffers from the same problem.
Exactly. I understand what you mean and I won't suffer from the same
problem.
After comparing pids from compositor's and the client's, I'll bypass to
check of client's privilege
when the client equals to the compositor.

>Upstream Weston never sends requests to itself, FWIW. It does use
>socketpair() when launching special clients, though.

>Yes, this is clear, assuming the security context information you
>receive is actually always correct. I would assume it does not suffer
>from the same caveat as getsockopt(SO_PEERCRED), but I don't know that.
Yes, as I also think, the security context must always be correct when I
pass the exact client's fd.
The library to get the security contexts from the file descriptor must
guarantee that
the returned contexts are credible.

Thanks and regards,
Sung-Jin Park

------- Original Message -------
Sender : Pekka Paalanen<ppaalanen at gmail.com>
Date   : 2016-01-13 19:35 (GMT+09:00)
Title  : Re: [PATCH] server: Add an API to get the socket fd for a client

 On Wed, 13 Jan 2016 10:02:18 +0000 (GMT)
박성진 <sj76.park at samsung.com> wrote:

> Samsung Enterprise Portal mySingle
>
> Pekka Paalanen, thank you for your review on this. :)
>
>
>
> >The fd may not always be from a socket file, it can also be from a call
> >to socketpair(2).
>
> Yes, exactly.
>
> >Please refer to wl_client_get_credentials() for the
> >caveat there, and evaluate whether it applies to your use case.
> >wl_client_get_fd() doc should probably have a "see also
> >wl_client_get_credentials()" so that someone reading the doc finds out
> >about socketpair().
>
> I'll append "see also wl_client_get_credentials() to wl_client_get_fd()
doc. :)
>
>
>
> Regarding your recommendation, as you meant, if I just need to
distinguish between
> the client's request and the request from compositor itself, it'll be
better to use
> wl_client_get_credentials() because comparing between the compositor's
uid and
> the uid from the function will be enough to make a decision for sth.

Hi,

sorry, that sounds completely bogus and I never implied anything like
that.

socketpair() is used for creating a connection before fork()'ing and
exec()'ing a client process, so that the process starts with an already
open connection. In that case, wl_client_get_credentials() provides
wrong information. Particularly the returned PID will be the
compositor's, not the client's. I do not know if the security context
you are interested in suffers from the same problem.

Upstream Weston never sends requests to itself, FWIW. It does use
socketpair() when launching special clients, though.

> In my use case, I would like to get the client fd and check whether the
client
> has the needed privilege for doing sth with a request. The security
context getting from
> the client fd will be used to check the client's privilege.

Yes, this is clear, assuming the security context information you
receive is actually always correct. I would assume it does not suffer
from the same caveat as getsockopt(SO_PEERCRED), but I don't know that.

Thanks,
pq
<p> </p><p> </p>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20160115/ba3a8bc3/attachment-0001.html>


More information about the wayland-devel mailing list