headers
Brandon Allbery | 1 Sep 2011 02:16
Picon
Gravatar

Re: Why was the macports user implemented

On Wed, Aug 31, 2011 at 15:26, Rodolfo Aramayo <raramayo <at> gmail.com> wrote:
Great. Good explanation. Thanks, but then that begs the question as to
why the files in '/opt/local/' are not owned by macports:macports and
instead by 'root:admin and/or root:wheel'? Am I missing something in
here??

You don't want to allow Portfiles to remove random files owned by you; likewise, you don't want to allow it to remove random files installed by other ports (which you have implicitly validated by "port install"ing them as some user other than the macports user; this is normally root but might be yourself or some other user if you chose).  The port build environment is set up to protect not only your files but also the rest of MacPorts.  Ideally it'd be a sandbox in which only the port's own working files could be modified by a rogue command, but MacPorts isn't quite there yet.

--
brandon s allbery                                      allbery.b <at> gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

<div><div dir="ltr">On Wed, Aug 31, 2011 at 15:26, Rodolfo Aramayo <span dir="ltr">&lt;<a href="mailto:raramayo <at> gmail.com">raramayo <at> gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote">
Great. Good explanation. Thanks, but then that begs the question as to<br>
why the files in '/opt/local/' are not owned by macports:macports and<br>
instead by 'root:admin and/or root:wheel'? Am I missing something in<br>
here??<br>
</blockquote>
<div><br></div>
<div>You don't want to allow Portfiles to remove random files owned by you; likewise, you don't want to allow it to remove random files installed by other ports (which you have implicitly validated by "port install"ing them as some user other than the macports user; this is normally root but might be yourself or some other user if you chose). &nbsp;The port build environment is set up to protect not only your files but also the rest of MacPorts. &nbsp;Ideally it'd be a sandbox in which only the port's own working files could be modified by a rogue command, but MacPorts isn't quite there yet.</div>
<div><br></div>
</div>-- <br>brandon s allbery &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:allbery.b <at> gmail.com" target="_blank">allbery.b <at> gmail.com</a><br>wandering unix systems administrator (available) &nbsp; &nbsp; (412) 475-9364 vm/sms<br><br>
</div></div>
Permalink | Reply | 0 comments |
headers
Gregory Seidman | 1 Sep 2011 03:38

Re: Why was the macports user implemented

On Wed, Aug 31, 2011 at 03:09:33PM -0400, Jeremy Lavergne wrote:
> > Please explain to me like if I were a four-year old, why was the user
> > 'macports' implemented?
> 
> The user was created to address this problem:
> Portfiles and the packages they install can contain arbitrary code, and
> should not be trusted unless they are signed and that packager is trusted.
[...]
> The typical way of implementing this is creating a user and group, so
> permissions on files can be set to `macports:macports`.

While we're on the topic, I recently got a new Mac and used the OS X
Migration Assistant to move stuff over. It automatically copied all of
macports, but did not create the macports user and group. I eventually did
it manually (by digging into the Makefile for the MacPorts source install),
but I was wondering if there was some automated way to recreate the user if
it gets blown away somehow.

Yes, I understand that this is a rare occurrence, and I'm not saying there
necessarily *should* be an automated way, I'm just wondering if there is. I
could also envision a "ports sanity-check" command that not only recreates
the user but checks into any number of potential issues.

--Greg
Permalink | Reply | 1 comment |
headers
Ryan Schmidt | 1 Sep 2011 04:51
Favicon

Re: Why was the macports user implemented


On Aug 31, 2011, at 20:38, Gregory Seidman wrote:

> On Wed, Aug 31, 2011 at 03:09:33PM -0400, Jeremy Lavergne wrote:
>>> Please explain to me like if I were a four-year old, why was the user
>>> 'macports' implemented?
>> 
>> The user was created to address this problem:
>> Portfiles and the packages they install can contain arbitrary code, and
>> should not be trusted unless they are signed and that packager is trusted.
> [...]
>> The typical way of implementing this is creating a user and group, so
>> permissions on files can be set to `macports:macports`.
> 
> While we're on the topic, I recently got a new Mac and used the OS X
> Migration Assistant to move stuff over.

That's not particularly supported. Quite often when people migrate they're also switching OS version or
processor architecture, in which case a full rebuild of all ports is required. We document this on our
migration page:

https://trac.macports.org/wiki/Migration

> It automatically copied all of
> macports, but did not create the macports user and group. I eventually did
> it manually (by digging into the Makefile for the MacPorts source install),
> but I was wondering if there was some automated way to recreate the user if
> it gets blown away somehow.

The only automated way I know of would be to reinstall MacPorts, which is one of the steps in the migration
instructions linked to above.

> Yes, I understand that this is a rare occurrence, and I'm not saying there
> necessarily *should* be an automated way, I'm just wondering if there is. I
> could also envision a "ports sanity-check" command that not only recreates
> the user but checks into any number of potential issues.

I believe MacPorts already includes a sanity check for whether the macports user exists; if it does not, you
should be getting errors when running any commands that would use that user.
Permalink | Reply | 0 comments |
headers
Lawrence Francell | 1 Sep 2011 15:14
Favicon

Re: Updating Mac OS X Server 10.6.8 amavisd-new

Super,

Thank you, this has me pointed in the right direction. 

I appreciate your answers and your time
Lawrence Francell

On Aug 31, 2011, at 5:18 PM, Ryan Schmidt wrote:

> 
> On Aug 31, 2011, at 16:41, Lawrence Francell wrote:
> 
>> If I use the macports installer, will it update the current version of amavisd-new on 10.6.8 or just
install a new version?
> 
> It will install a separate version in the MacPorts prefix /opt/local. MacPorts is designed to be separate
from software that's part of OS X.
> 
> 

On Aug 31, 2011, at 4:56 PM, Jeremy Lavergne wrote:

>> The question I pose to the port-community, If I use the macports
>> installer, will it update the current version of amavisd-new on 10.6.8 or
>> just install a new version? As well, if it does install a new version what
>> should I need to change to make use of 2.6.6 rather than the old version.
> 
> At the very minimum you'll need to disable the launchd item for the system
> version, and then enable the one for the MacPorts package.
> 
> When I tried this last (years ago), the output from amavisd itself was
> most helpful. So try launching it not as a daemon a few times to see
> what's going on. For example, certain types of decoders (for various
> attachments) might not be available based on what other packages are
> installed on the system. You can spot these in the output when amavisd
> starts.
> 
>
Permalink | Reply | 0 comments |
headers
Richard DeLaurell | 1 Sep 2011 16:39
Picon

registry errors across versions

I know this must be an old issue, but I cannot find the answer so sorry for asking again.

I ran port_cutleaves and got a host of "registry errors: <port_name> not registered" for those ports which were found and which I asked to uninstall.

Is this b/c those ports were installed unter 1.9.x and now I'm trying to uninstall under 2.0.1?

If it is what I need to do, how can the registry be resolved across versions?

Thanks for any help--

Richard

<div><p>I know this must be an old issue, but I cannot find the answer so sorry for asking again.<br><br>I ran port_cutleaves and got a host of "registry errors: &lt;port_name&gt; not registered" for those ports which were found and which I asked to uninstall.<br><br>Is this b/c those ports were installed unter 1.9.x and now I'm trying to uninstall under 2.0.1?<br><br>If it is what I need to do, how can the registry be resolved across versions?<br><br>Thanks for any help--<br><br>Richard<br></p></div>
Permalink | Reply | 1 comment |
headers
Cantor, Scott | 1 Sep 2011 16:49
Picon
Favicon

Getting UserName set in a launchd plist

I found an old bug open on adding support for additional keywords in the
startup plist created by the macport system, but it doesn't appear to have
been addressed. The documentation simultaneously says that using
start/stop instead of direct exec is less good, but that doesn't really
fly if you're going to support a daemon running as a different user.

A contributor to my project suggested a workaround, and I wanted to ask if
it was kosher or not. He found the right macros to locate the plist and
suggested:

reinplace 
"s|^<key>ProgramArguments</key>|<key>UserName</key><string>${runuser}</stri
ng>\\
<key>GroupName</key><string>${runuser}</string>\\&|g"
${prefix}/etc/${startupitem.location}/${startupitem.uniquename}/${startupit
em.plist}

Whether that's exactly correct or not, is it a bad idea to rely on those
macros or to do that replacement?

TIA,
-- Scott
Permalink | Reply | 5 comments |
headers
Ryan Schmidt | 1 Sep 2011 22:31
Favicon

Re: Getting UserName set in a launchd plist

On Sep 1, 2011, at 09:49, Cantor, Scott wrote:

> I found an old bug open on adding support for additional keywords in the
> startup plist created by the macport system, but it doesn't appear to have
> been addressed. The documentation simultaneously says that using
> start/stop instead of direct exec is less good, but that doesn't really
> fly if you're going to support a daemon running as a different user.
> 
> A contributor to my project suggested a workaround, and I wanted to ask if
> it was kosher or not. He found the right macros to locate the plist and
> suggested:
> 
> reinplace 
> "s|^<key>ProgramArguments</key>|<key>UserName</key><string>${runuser}</stri
> ng>\\
> <key>GroupName</key><string>${runuser}</string>\\&|g"
> ${prefix}/etc/${startupitem.location}/${startupitem.uniquename}/${startupit
> em.plist}
> 
> Whether that's exactly correct or not, is it a bad idea to rely on those
> macros or to do that replacement?

I would say if you're going to be modifying a plist, you should be using a tool designed to do so, like
"defaults" or "PlistBuddy". Not sure if we have any Tcl functions or wrappers around those utilities in
MacPorts already, but having a wrapper around PlistBuddy especially would be nice of us to do, since
PlistBuddy is sometimes hard to find. It's installed in /usr/libexec as of Snow Leopard, but before that,
you have to go hunting through various OS X installer receipts to find a copy. Many Apple Installer
packages use PlistBuddy, and have code that does that locating. Here's some other code that does that:

http://prowiki.isc.upenn.edu/wiki/Manipulating_Plists#Locating_a_copy_of_PlistBuddy

The rest of that article may also be relevant / helpful.
Permalink | Reply | 4 comments |
headers
Cantor, Scott | 1 Sep 2011 22:34
Picon
Favicon

Re: Getting UserName set in a launchd plist

On 9/1/11 4:31 PM, "Ryan Schmidt" <ryandesign <at> macports.org> wrote:
>
>I would say if you're going to be modifying a plist, you should be using
>a tool designed to do so, like "defaults" or "PlistBuddy".

That really addresses a different issue. Either way, one would have to
locate the plist to begin with, and my question was essentially whether
locating it with those macros was publically stable and accepted practice.

-- Scott
Permalink | Reply | 3 comments |
headers
Ryan Schmidt | 1 Sep 2011 22:34
Favicon

Re: registry errors across versions


On Sep 1, 2011, at 09:39, Richard DeLaurell wrote:

> I know this must be an old issue, but I cannot find the answer so sorry for asking again.
> 
> I ran port_cutleaves and got a host of "registry errors: <port_name> not registered" for those ports
which were found and which I asked to uninstall.
> 
> Is this b/c those ports were installed unter 1.9.x and now I'm trying to uninstall under 2.0.1?
> 
> If it is what I need to do, how can the registry be resolved across versions?

Could it be you're running an old version of port_cutleaves that doesn't understand the SQLite registry
that is now mandatory in MacPorts 2? Try upgrading port_cutleaves.

Also, you may not need port_cutleaves anymore. I happen to still like it, but much of its functionality is in
MacPorts base now; you can use "port installed leaves" to see what leaves you have, and "sudo port
uninstall leaves" uninstall them. If the list of leaves isn't accurate, check "port installed
requested"; that's the list of ports MacPorts thinks you want. If it's missing entries, you can use "sudo
port setrequested" to add a port to that list, or "sudo port unsetrequested" to remove a port. Then
"leaves" should be accurate.
Permalink | Reply | 0 comments |
headers
Troy Telford | 1 Sep 2011 22:45
Picon
Gravatar

Macports selfupdate failed

I just tried to run port -v selfupdate, and the update to MacPorts 2.0.2 fails.

It appears the problem is MacPorts is grabbig SQLite from

/Library/Frameworks/Mono.framework/Versions/2.10.3/include/sqlite3.h

With the final error being:
/usr/bin/cc -dynamiclib -g -O2 -W -Wall -pedantic  
-I/Library/Frameworks/Mono.framework/Versions/2.10.3/include    
-Wl,-single_module registry.o util.o entry.o entryobj.o 
../cregistry/cregistry.a -o registry.dylib 
-L/System/Library/Frameworks/Tcl.framework/Versions/8.5 -ltclstub8.5   
-L/Library/Frameworks/Mono.framework/Versions/2.10.3/lib -lsqlite3
ld: warning: ignoring file 
/Library/Frameworks/Mono.framework/Versions/2.10.3/lib/libsqlite3.dylib, 
file was built for unsupported file format which is not the 
architecture being linked (x86_64)

Obviously, part of the problem is that the version of SQlite being 
found/used is from the Mono SDK (installed from go-mono.com),  
installed at /Library/Frameworks/Mono.framework.

The odd thing:  As far as I can tell, MacPorts should be using the 
frameworks in /opt/local/Library/Frameworks:
(from the configure script output:)
checking for Frameworks installation directory... /opt/local/Library/Frameworks

What do I need to do to get 'port selfupdate' to ignore the Mono framework in
	/Library/Frameworks
And use the one(s) in
	/opt/local/Library/Frameworks?

Thanks.
--

-- 
Troy Telford
Permalink | Reply | 4 comments |

Gmane