Menu
▾
▴
#134 Run as 'fink-bld' for build-as-nobody
This patch will make fink look for a 'fink-bld' user if run with --build-
as-nobody. If that user exists, the build is done under 'fink-bld', if not,
the user 'nobody' is used, but a warning is issued to install the 'passwd'
package that contains the 'fink-bld' user.
This was motivated by a comment of 'wsanchez' on the #svn channel,
saying:
" Just FYI. You should never start a process as user (or group) "nobody".
User nobody exists for NFS' maproot= feature. The idea being that you
can map the root user to nobody on the NFS filesystem, there by giving
root access to no files that aren't world-readable."
A couple of things that need to be discussed:
- Is 'finger' an appropriate method to check for the existence of user
'fink-bld'?
- Would the build_as_user_group method better be in Service.pm
instead of Config.pm?
- Is the warning appropriate or should we disallow 'nobody' alltogether?
- Why did we do
chowname ':admin', $destdir
and not
chowname 'root:admin', $destdir
? That would make the code a little simpler.
build_as_fink-bld.patch Rev. 1
Logged In: YES
user_id=286406
As recommended by dmacks, it makes more sense to use getpwnam instead
of finger. See r2 of patch.
build_as_fink-bld.patch Rev. 2
Logged In: YES
user_id=535292
Originator: NO
Instead of having the caller of build_as_user_group() specify which type(s) of data to return and then having a giant if/else/else to return them, might be better to return a hash of all the data. No need for all that overhead, and it's just hard-coded text strings so no tradeoff cost of calculating data that isn't wanted. Also would allow caller to get several types of data all at once instead of having to make several calls to the function.
For example:
$result = {qw/ user nobody group nobody user:group nobody:nobody /};
Then PkgVersion can do:
my $build_as_user_group = $config->build_as_user_group();
chowname $build_as_user_group->{'user:group'}, $destdir or
Logged In: YES
user_id=535292
Originator: NO
Major inconsistency in calling... Foo::Bar::baz($a,$b) and $thing->baz($a,$b) do *not* give the same parameters to baz(). There's no $self in the former.
build_as_fink-bld.patch Rev. 3
Logged In: YES
user_id=286406
Originator: YES
Attached build_as_fink-bld.patch Rev. 3.
We could still simplify the code quite a bit by doing:
chowname 'root:admin', $destdir
instead of
chowname ':admin', $destdir
Is there a reason why 'root' is omitted? Does it hurt having 'root:admin'?
File Added: fink_build_as_fink-bld_r3.patch
build_as_fink-bld.patch Rev. 4
Logged In: YES
user_id=286406
Originator: YES
Attached build_as_fink-bld.patch Rev. 4
Simplified to call chowname 'root:admin', $destdir instead of chowname ':admin', $destdir
Seems to work fine here.
File Added: fink_build_as_fink-bld_r4.patch
Logged In: YES
user_id=535292
Originator: NO
Looks like a quite nice API now!
Gotta fix the Config.pm docs for the new "no parameters" syntax.
More importantly, Services is still using a different calling syntax than PkgVersion (see my comment from 2006-12-05 19:01). We probably want the object-oriented way (how PkgVersion is doing it) because Config is moving towards being more OOish. And if that's the way, then the actual function should do a 'my $self = shift;'. Yeah, even if $self isn't used at this point, keeps ourselves consistent about it being OOish...if we want it in the future it's all ready instead of to o back and find any place we forgot to handle it properly.
Logged In: YES
user_id=535292
Originator: NO
Should also check that group "fink-bld" exists (in addition to that user) before passing that back as a group name.
build_as_fink-bld.patch Rev. 5
Logged In: YES
user_id=286406
Originator: YES
Attached build_as_fink-bld.patch Rev. 5
- now also checking for 'fink-bld' group
- Config.pm docu updated
- Now using the non-OO Fink::Config:: form to call build_as_user_group, since we would need to use Fink::Config in Services.pm otherwise
What else?
File Added: fink_build_as_fink-bld_r5.patch
Logged In: YES
user_id=286406
Originator: YES
This has been applied 2006-12-09