From owner-freebsd-bluetooth@FreeBSD.ORG Tue Apr 14 23:22:27 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 2F141106567D for ; Tue, 14 Apr 2009 23:22:27 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.8]) by mx1.freebsd.org (Postfix) with ESMTP id 050928FC0A for ; Tue, 14 Apr 2009 23:22:26 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: (qmail 24381 invoked from network); 14 Apr 2009 23:22:26 -0000 Received: from aldan.algebra.com (mi@[216.254.65.224]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 14 Apr 2009 23:22:25 -0000 Message-ID: <49E51AAF.4060907@aldan.algebra.com> Date: Tue, 14 Apr 2009 19:22:23 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.21 (X11/20090407) MIME-Version: 1.0 To: Maksim Yevmenkin 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> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit 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 23:22:27 -0000 Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ): > 2009/4/14 Mikhail T. : > >> Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ): >> >>> 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 = 1; >> + if (getuid() == 0) >> + context.secure = 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. > Oh, that must be why I couldn't start obexapp as myself before... So, all of those getuid() calls are no-ops too? Either they need to be eliminated, or, if other ways of authenticating to sdp are in the works, ability to chroot should not be a requirement. > 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. > Right, of course. The symlinks can point to . or to some external /home/dropoff -- same thing. > >> 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. > It is not expensive, but not needed either :) After a chdir succeeds, the chroot can go simply into "." >> 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. > The gist of the PATH_MAX/MAXPATHLEN vs. pathconf() controversy is that the latter may change after the program is compiled. Thus relying on ANY compile-time buffer-length as being "long enough" is potentially dangerous (and almost always wasteful). Logging the actual directory (as can be determined by getwd(NULL) after chdir-ing, but before chroot-ing), rather than the name of the symlink can be seen as beneficial too. Yours, -mi