Date: Wed, 21 Feb 2007 22:23:48 +0000 (GMT) From: Iain Hibbert <plunky@rya-online.net> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: freebsd-bluetooth@freebsd.org Subject: Re: obexapp 1.4.5 Message-ID: <1172096628.479674.24514.nullmailer@galant.ukfsn.org> In-Reply-To: <bb4a86c70702210955p59ee0a28i19ea12c87e48d86a@mail.gmail.com> References: <bb4a86c70701300920g47111252n9c50cef20221973a@mail.gmail.com> <bb4a86c70701301952y322a5174m762889c986986768@mail.gmail.com> <Pine.NEB.4.64.0702201732410.9463@localhost.> <1171997469.725737.13812.nullmailer@galant.ukfsn.org> <bb4a86c70702210955p59ee0a28i19ea12c87e48d86a@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On Wed, 21 Feb 2007, Maksim Yevmenkin wrote: > well, the sdp_session_open() is called before setgid()/setuid() so > sdpd will mark this session as "privileged". once sdp session is open, > obexapp can drop its privileges and still be able to register service > with sdpd. I think the problem with my implementation of this is that the SCM_CREDS information is sent alongside the first normal message, and because that are not sent until after the setuid(), the credentials have changed.. As I recall, for PEER_CREDS, sdpd actively queries the remote credentials when as the socket is open - (it seems that a slight race condition could exist there, or are the credentials passed the ones that were used to open the socket?) I will look into this a bit more, maybe if I arrange to send() an zero length message before changing the uid it may work, though I'm not sure how well sdpd will handle that.. iainhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1172096628.479674.24514.nullmailer>