Re: How should we handle fink-bld?

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]



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