MacPorts is hijacking account on MacOSXServer

[Rodolfo Aramayo]

On Mon, Jul 25, 2011 at 16:09, Rainer Müller <raimue at macports.org> wrote:
> On 2011-07-25 21:44 , Rodolfo Aramayo wrote:
>> The latest installation of MacPorts is taking over mobile accounts on
>> MacOSXServer
>
> AFAIK mobile account means they have a home exported over the network?
> I am not sure if it is NIS/yp, but is this a similar solution?
>
>> Obviously the installer does not determine the presence of 'mobile'
>> accounts and finds the next available UniqueID number available and
>> assigns it to the 'macports:staff'
>
> The same method has been used for years now to create new system users
> for Portfiles. So if you installed anything which required a new user,
> you would have run into this problem before, for example the messagebus
> user for dbus, polkituser for policykit or mysql for mysql4/mysql5.
>
> If this method is really a problem, you already that before 2.0.0.
>

Yes, But I did not run into this problem before and now Macports has
gracefully hijacked one of my graduate students account. The guy is
pretty happy about it as he does not have to work but...I am not...;))

I have three servers and Macport installed itself as follows in all of them:

==========
g00
RecordName: nobody							-2:-2
RecordName: root					       0:0
RecordName: daemon						  1:1
RecordName: messagebus				          507:500
RecordName: polkituser				                  508:502
RecordName: macports						  509:1026

a00
RecordName: nobody							-2:-2
RecordName: root							0:0
RecordName: daemon							1:1
RecordName: messagebus						505:500
RecordName: polkituser						508:502
RecordName: macports						509:1027

a10
RecordName: nobody							-2:-2
RecordName: root							0:0
RecordName: daemon							1:1
RecordName: messagebus						505:500
RecordName: polkituser						506:502
RecordName: macports						510:1027
==========

>> The problem this creates is obvious, mobile users using that
>> particular UniqueID lose control over their directories and files
>>
>> While the problem can be easily fixed by reverting the usernames to
>> their old ones, it is not clear to me what implications this will have
>> on the macports user. Please advice here
>>
>> Also I do not understand why the '/opt' directory is not now owned by
>> the 'macports:staff' user
>
> As Ryan pointed out, it's /opt/local.
>
> Why should it be owned by macports:staff?
>
> The macports user is being used to drop privileges while building. It is
> not meant to own any files on your system as that would defeat its purpose.
>
> Rainer
>

Hmmm...Drop privileges while building...In that case I will have to
manually create a macport user with an UID that does NOT collide with
my existent users. Which group should then this be::

Should it be: macports:staff or macports:wheel??

obviously if I delete the macports user...bad things will happen..yes??


Thanks

--R