Date: Tue, 14 Apr 2009 19:22:23 -0400 From: "Mikhail T." <mi+thun@aldan.algebra.com> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: RFC: obexapp - virtual root folder for each device Message-ID: <49E51AAF.4060907@aldan.algebra.com> In-Reply-To: <bb4a86c70904141546x6c6076e3rbd14d822d0349662@mail.gmail.com> References: <bb4a86c70904131640n7cf471c0o7a56a43d722a90e1@mail.gmail.com> <49E3DB35.4030601@aldan.algebra.com> <bb4a86c70904131909k44aba88dk126d25a4f1fc3744@mail.gmail.com> <49E41DBB.5090805@aldan.algebra.com> <bb4a86c70904140934h5b967efby4e3238bd97c5ca01@mail.gmail.com> <49E4CAE1.6090506@aldan.algebra.com> <bb4a86c70904141155h205b78caq95d5f2d30a583376@mail.gmail.com> <49E4EA14.80300@aldan.algebra.com> <bb4a86c70904141438y2f8742efxa9c640f21581b2ed@mail.gmail.com> <49E50A59.9000606@aldan.algebra.com> <bb4a86c70904141546x6c6076e3rbd14d822d0349662@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin ΞΑΠΙΣΑΧ(ΜΑ): > 2009/4/14 Mikhail T. <mi+thun@aldan.algebra.com>: > >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E51AAF.4060907>