Re: obexapp 1.4.5

> > 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

My thought was that a zero length message (sent at the end
of sdp_open_local()) would create a message event for sdpd
that only contains the SCM_CREDS message. Thus, we pass the
credentials before they are changed..

I will try it, later..

iain
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On 2/22/07, Iain Hibbert <plunkyrya-online.net> wrote:
> > > 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
>
> My thought was that a zero length message (sent at the
end
> of sdp_open_local()) would create a message event for
sdpd
> that only contains the SCM_CREDS message. Thus, we pass
the
> credentials before they are changed..

ah, i see. i was thinking exactly the same, except that i
would like
to make authentication procedure between local sdp client
and local
sdp server well defined and mandatory.

right now, sdpd simply uses getsockopt() to pull cached
(inside
socket) peers credentials (i.e. no messages flow between the
client
and the server)

thanks,
max
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On Thu, 22 Feb 2007, Maksim Yevmenkin wrote:

> ah, i see. i was thinking exactly the same, except that
i would like
> to make authentication procedure between local sdp
client and local
> sdp server well defined and mandatory.

Hmm, maybe with an AUTH Request/Response rather than
credential check? I'm
not sure if that would be a lot of work..?

I had a thought before about adding an option to permit
group access to
the server (eg "-G staff"), and this would not
seem so very difficult to
implement (maybe even multiple groups..)

> right now, sdpd simply uses getsockopt() to pull cached
(inside
> socket) peers credentials (i.e. no messages flow
between the client
> and the server)

Yeah, thats a FreeBSD extension though and so far as I
recall, I think
there was some resistance to including it in NetBSD for
whatever reason.

I didn't get around to the zero length packets, but the
following diff
which moves the ServerRegister up before the setuid() calls
does the job
for NetBSD at least..

iain

--- server.c.orig	2007-01-30 00:35:23.000000000 +0000
+++ server.c
 -149,6
+149,19  obexapp_server(obex_t *handle)
 			strlcpy(context->root, pw->pw_dir, PATH_MAX);
 	}

+	log_info("%s: Starting OBEX server", __func__);
+
+	if (OBEX_SetTransportMTU(handle, context->mtu,
context->mtu) < 0) {
+		log_err("%s(): OBEX_SetTransportMTU failed",
__func__);
+		goto done;
+	}
+
+	if (OBEX_ServerRegister(handle, (struct sockaddr *)
&context->addr,
+			sizeof(context->addr)) < 0) {
+		log_err("%s(): OBEX_ServerRegister failed",
__func__);
+		goto done;
+	}
+
 	if (getuid() == 0) {
 		if (context->secure) {
 			if (chroot(context->root) < 0) {
 -184,19
+197,6  obexapp_server(obex_t *handle)
 		goto done;
 	}

-	log_info("%s: Starting OBEX server", __func__);
-
-	if (OBEX_SetTransportMTU(handle, context->mtu,
context->mtu) < 0) {
-		log_err("%s(): OBEX_SetTransportMTU failed",
__func__);
-		goto done;
-	}
-
-	if (OBEX_ServerRegister(handle, (struct sockaddr *)
&context->addr,
-			sizeof(context->addr)) < 0) {
-		log_err("%s(): OBEX_ServerRegister failed",
__func__);
-		goto done;
-	}
-
 	log_debug("%s(): Entering event processing
loop...", __func__);

 	for (error = 0, context->done = 0; !context->done; )
{
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"

On 2/22/07, Iain Hibbert <plunkyrya-online.net> wrote:
> On Thu, 22 Feb 2007, Maksim Yevmenkin wrote:
>
> > ah, i see. i was thinking exactly the same, except
that i would like
> > to make authentication procedure between local sdp
client and local
> > sdp server well defined and mandatory.
>
> Hmm, maybe with an AUTH Request/Response rather than
credential check? I'm
> not sure if that would be a lot of work..?

i doubt that we need to go this route. that is just for the
local
clients. imo, credentials should be more then enough.

> I had a thought before about adding an option to permit
group access to
> the server (eg "-G staff"), and this would
not seem so very difficult to
> implement (maybe even multiple groups..)

yes, i had the same idea too. it's trivial to implement -
just need to
pass list of user ids and/or group ids that allowed to
register
services with sdpd. then check credentials against those
lists.

> > right now, sdpd simply uses getsockopt() to pull
cached (inside
> > socket) peers credentials (i.e. no messages flow
between the client
> > and the server)
>
> Yeah, thats a FreeBSD extension though and so far as I
recall, I think
> there was some resistance to including it in NetBSD for
whatever reason.

ok

> I didn't get around to the zero length packets, but the
following diff
> which moves the ServerRegister up before the setuid()
calls does the job
> for NetBSD at least..

looks reasonable. i will take a closer look and commit this
and other
patches later.

thanks,
max
_______________________________________________
freebsd-bluetoothfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-blu
etooth
To unsubscribe, send any mail to
"freebsd-bluetooth-unsubscribefreebsd.org"