[90075] trunk/base/src/macports1.0/macports.tcl

[Jeremy Huddleston]

Ok, so you want to support the situation where a user *doesn't* want to accept it for the whole machine, so you are using the logged in user's preferences.  That should "just work" so long as the logged in user has given read access to the preferences to the macports user, but that is not default and is probably less secure than just copying them.

Thanks for alleviating my fears.  I'll go back to catching up on tons of mail...

--Jeremy


On Feb 24, 2012, at 07:31, James Berry wrote:

> I agree with Josh. Consider that we're just saying "I'm going to be calling myself 'macports' for a while, and I want Xcode to have my preferences while I do." The macports user is a user that macports controls, and is really just a proxy for the current user while macports is running. The irony is that with "sudo xcodebuild -license" you would be doing something far more expansive: accepting the license for all users of the machine ;)
> 
> James
> 
> On Feb 24, 2012, at 4:06 AM, Joshua Root wrote:
> 
>> We're not saving EULA acceptance, just putting it somewhere that
>> xcodebuild can find it when we're running as the macports user.
>> 
>> If a different user runs port, their own plist is copied, so if they
>> haven't accepted the EULA they can't still use xcode based on a previous
>> user's acceptance. (Whereas that's exactly what can happen if one user
>> runs 'sudo xcodebuild -license' and then another user runs port.)
>> 
>> Can we even tell whether xcodebuild or xcrun is failing because it wants
>> EULA acceptance as opposed to some other reason?
>> 
>> - Josh
>> 
>> On 2012-2-24 20:56 , Jeremy Huddleston wrote:
>>> Wait a minute... I'm jumping in a bit at the end here and missed a bit of this progress, so apologies if I'm a bit off based with my limited context... are you guys saving EULA acceptance for the user by copying the plist?  IANAL, but that seems far inside the not-quite-legal zone.
>>> 
>>> Macports should do no copying of the plist or otherwise "mess" with the license setting for the user.  If it encounters a problem, it should tell the user to run 'sudo xcodebuild -license' ... not copy preferences around all over the place.  Again, IANAL, but that sounds like the safest bet to me.
>>> 
>>> --Jeremy
>>> 
>>> On Feb 21, 2012, at 12:08 PM, Dan Ports <dports at macports.org> wrote:
>>> 
>>>> On Wed, Feb 22, 2012 at 02:39:42AM +1100, Joshua Root wrote:
>>>>> And why did Dan set the ownership in the first place? I can see that
>>>>> making sense in the per-port dirs but not really in the global one.
>>>> 
>>>> Without it, the plist had 0600 permissions and it was owned by root, so
>>>> xcodebuild couldn't access it once we dropped privileges. Changing the
>>>> permissions works to.
>>>> 
>>>> Speaking of which, do we actually need to create the plist in both the
>>>> global and per-port home directories? It looks like only the global one
>>>> is actually used, regardless of $HOME. (This surprised me, I figured
>>>> it'd be the other way around.)
>>>> 
>>>> Dan
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>