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" (<a href="http://patchwork.freedesktop.org/patch/70475/">http://patchwork.freedesktop.org/patch/70475/</a>) 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<<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> 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) 박성진 <<a href="mailto:sj76.park@samsung.com">sj76.park@samsung.com</a>> 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