Re: How should we handle fink-bld?

On 4/23/12 9:36 AM, Daniel Macks wrote:
> On Mon, 23 Apr 2012 09:12:17 -0700, Alexander Hansen
> <[email protected]> wrote:
> On 4/23/12 6:15 AM, Dustin Cartwright wrote:
>> > > A key question is: what are the benefits of building as "fink-bld"
>> over
>> > building as "nobody"? I suppose that in theory fink-bld is more
>> > isolated, but practically speaking, does it matter? On my computer, the
>> > only files in /private and /usr which belong to "nobody" are a
>> temporary
>> > folder, an empty launchd plist, and the "locate" database (I didn't
>> have
>> > the patience to search the whole file hierarchy, but /private includes
>> > /etc and /var). An errant build causing damage to any of these is not a
>> > significant concern. > > Building as nobody is lightly tested
>> compared to building as fink-bld. > On the other hand, adding fink-bld
>> involves touching the user database,
>> > which inherently more risky than running the compile scripts as
>> "nobody."
>> > > I can see the argument that in some ways, it's simpler to just force
>> > everyone to install fink-bld, but in other ways it's more
>> complicated. > If fink-bld is optional, then there's no need to worry
>> about making sure
>> > it gets added during the upgrade from 0.32 to 0.33 and different ways
>> > that can fail. There's no need to worry about the admittedly unlikely
>> > scenario of the system already having a user with UID 266, and what
>> > would happen if fink-bld gets added with the same UID. > > I wasn't
>> paying attention to fink development when --build-as-nobody was
>> > introduced, so maybe it's clear to everyone else why "fink-bld" is much
>> > better than "nobody." However, from my perspective, the discussion
>> > quickly jumped to the mechanics of adding "fink-bld" without every
>> > discussing whether it's really necessary. Maybe it is, but I just
>> wanted
>> > to raise the possibility of avoiding it.
>> We originally used the system's "nobody" user, but after some discussion
>> it was decided that there were potential risks associated with that
>> (which I can't remember offhand).
>> It was decided to set up our own unpriviliged user which had a low
>> probability of any upstream package using for anything. 
> 
> I originally wrote it to use "nobody" assuming that "nobody" was exactly
> that--nobody--and that the point of a "nobody" account was specifically
> as a generic completely non-existing and unprivleged user. And then
> someone reminded me that Assuming is Bad, with details and pointers in
> TFM. Turns out that "nobody" is used by several system-level network
> services that really wouldn't appreciate our interference. The whole
> point of --build-as-nobody is to have a user who cannot do any damage
> (except simple resource consumption), no matter how many mistaken
> pathname assumptions and overly greedly filename globs or other system
> things it tries to delete or alter. So now we have our *own* nobody user
> that can't even interfere with other nobodies that exist.
> One of the annoying things about our passwd implementation in my view is
> exactly one of Dustin's concerns: hardcoding the uid/gid by value, which
> creates the risk of trampling other locally created users (and therefore
> screws up everything about packages' privilege isolation). Would
> certainly be safer if fink said "create a user with this name" and allow
> dynamic assignment of the uid value, but *that* only is viable if
> everything in fink (including dpkg, the .tar format, and other parts of
> the toolchain) rely exclusively on name not value.
> dan
> 
>  --
> Daniel Macks
> [email protected]
> 
> 

Yeah.  I'm not sure what initially motivated hardcoding the uid and
gid--maybe details of the NetInfo command-line tools--but it doesn't
seem as necessary now.

We could probably do like what I've done in fink.info.in in master:
check whether the username exists, and if so, don't do anything and let
that user be used, provided that we're only looking by username and not uid.

-- 
Alexander Hansen, Ph.D.
Fink User Liaison
http://finkakh.wordpress.com/2012/02/21/got-job/

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
fink-core mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core