On 2/21/07, Iain Hibbert <[EMAIL PROTECTED]> wrote:
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..
ok
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 do not think so, from kern/uipc_usrreq.c
...
/*
* unp_peercred management:
*
* The connecter's (client's) credentials are copied from its
* process structure at the time of connect() (which is now).
*/
cru2x(td->td_ucred, &unp3->unp_peercred);
unp3->unp_flags |= UNP_HAVEPC;
/*
* The receiver's (server's) credentials are copied from the
* unp_peercred member of socket on which the former called
* listen(); unp_listen() cached that process's credentials
* at that time so we can use them now.
*/
...
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..
i'm not sure what are you suggesting
thanks,
max
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
