From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 22:46:44 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 744141065691 for ; Tue, 14 Apr 2009 22:46:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 26D208FC14 for ; Tue, 14 Apr 2009 22:46:44 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so1673447ywh.13 for ; Tue, 14 Apr 2009 15:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d2Z9dNz4/SwqDVZsZL1Yzx/8b+sDPymqDaS6h6zSG1A=; b=q+x6zCoW8onfC0/GZNSIz0T1WX7V4b+1PRMhKCsIR1uR3Pc8LyPa3fkvfWNrgsN9O+ Ep94Cznw32Oh8luoDTjv6/hPOSAbzc2eTIotB64DE4UXWul2WiHBYp4dem9AIFIHZU2X uDvJW7QOdK+xHH4Ogy2PRmJG3LnlGS0dkFncU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LjCBfx0LWRFzOoqvPCKuQXq7mTMHWJG35b7PJ283gOcuvhnHm1+NBXaYRsyw7fGw2r ng35TyG0caWqSaezO6KJGG+Pqsr0deIR+vENwE/XStYsRCNrTcDLJ8d54aEBTaKJf9ev 684toDzizxXBtbeBQ0wOFusX5G/cWBkWinFUg= MIME-Version: 1.0 Received: by 10.90.68.12 with SMTP id q12mr6201929aga.79.1239749203516; Tue, 14 Apr 2009 15:46:43 -0700 (PDT) In-Reply-To: <49E50A59.9000606@aldan.algebra.com> References: <49E3DB35.4030601@aldan.algebra.com> <49E41DBB.5090805@aldan.algebra.com> <49E4CAE1.6090506@aldan.algebra.com> <49E4EA14.80300@aldan.algebra.com> <49E50A59.9000606@aldan.algebra.com> Date: Tue, 14 Apr 2009 15:46:43 -0700 Message-ID: From: Maksim Yevmenkin To: "Mikhail T." Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: RFC: obexapp - virtual root folder for each device X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 22:46:45 -0000 2009/4/14 Mikhail T. : > Maksim Yevmenkin =CE=C1=D0=C9=D3=C1=D7(=CC=C1): >> hopefully the latest patch will work for everyone. >> > Little nits this time... > > 1. Even when the service is not running as root to begin with (and thus > chroot is impossible), a user owning multiple devices may wish to have > separate directories for each one. Yet, the new -R switch, as proposed, > requires successful chroot into a matching entry... It does not need to. > How about: > > + case 'R': /* virtualize root for each device */ > + context.vroot =3D 1; > + if (getuid() =3D=3D 0) > + context.secure =3D 1; > + break; > + > > chdir should be used instead of chroot in this case (-R was given, and a > matching entry is found, but we aren't running as root). well, a couple of things. for now, we always have to start obexapp as root because it needs to talk to sdpd(8) to register services. sdpd(8) is checking credentials (passed via unix sockets) and makes sure that the process, that is trying to register the service, has uid of 'root' user. so, strictly speaking this change is a no-op because getuid() will always be 0 or else obexapp will not start in server mode. also, i'd _really_ like to keep clients "jailed" under their virtual root folders. at least for now. as far as keeping and sharing files under the same root folder, i just thought of a way to "break" the latest patch: set up symlink that points to '.' under default root folder. obviously chdir() and chroot() conditions will be satisfied and you get your files dumped in the same directory. > 2. When going through the list of possible subdirectories-candidates, > hardcoding the number 3 is a bit dangerous. Using either > > sizeof(root)/sizeof(root[0]) > > or simply going, until hitting NULL: > > char const *root[] =3D { NULL, NULL, NULL, NULL }, **r; > ... > foreach (r -> root; *r; r++) { > > log_debug("%s(): Checking for %s/%s subdirectory", > __func__, context->root, *r); > ... > > would be a bit safer going forward -- what if some other parameter (such > as an environment variable) may some day be added to the list of > considerations? that's fine. i will fix it. > 3. After starting up, with the -R (or the -r) option, should/does not > the daemon chdir into the specified top-level directory? And if so, > there is no need to assemble the context->root with strlcat -- just > perform chdir into the relative root[n] (or *r in my example). The > chroot can then happen to ".". After chdir-ing, you can populate the > actual contet->root with getcwd(context->root, PATH_MAX) -- a faster > equivalent to using realpath(3). it does, chdir(), i.e. obexapp_server_set_initial_root() does it. strlcat() is not that expensive, imo. it can be changed, i guess. > This is not material, but the fewer cases, where a hard-coded PATH_MAX > is used instead of the POSIX-approved pathconf(2), the better... PATH_MAX comes from sys/syslimits.h, so, i thought it would be ok to use. another alternative was MAXPATHLEN which was the same. thanks, max