Opened 7 weeks ago

Last modified 7 weeks ago

#70938 new defect

macports-base does change the default users home path in some cases

Reported by: christophecvr (christophecvr) Owned by:
Priority: Normal Milestone:
Component: base Version: 2.10.99
Keywords: Cc:
Port:

Description (last modified by christophecvr (christophecvr))

I was creating a extra macports location in /opt. with command :

export PATH=/bin:/sbin:/usr/bin:/usr/sbin
MP_PREFIX=/opt/geditb
./configure --prefix=$MP_PREFIX --with-applications-dir=/Applications/Geditb --with-macports-user=christophe --without-startupitems --with-shared-directory --enable-readline
make
sudo make install

after installation sudden browser crashed (firefox) and other programs. Could not do anything anymore.
Restarted my mac and it opened with initial setup screen.

In finder I could not find my paths anymore woow ! (yes a little panic)

At the end I found the issue :
My home path was changed from :

/Users/<me>

to :

/opt/geditb/var/macports/home

This caused by the use of arg:
--with-macports-user=christophe

This arg is supposed to just change the user macports into another for the non root build phases.
according to configure manual.

  --with-no-root-privileges
                          specify that MacPorts should be installed in your
                          home directory
  --with-install-user=USER
                          specify user ownership of installed files
  --with-install-group=GROUP
                          specify group ownership of installed files
  --with-macports-user=USER
                          specify user to drop privileges to, if possible,
                          during compiles, etc.

Well this was a very unpleasant surprise I can tell.

Forgot to add: macos 10.15.7 Xcode 11.5 CommandLineTools 11.5 MacBookPro Mid 2010 intel i7 x86_64 arch

Change History (5)

comment:1 Changed 7 weeks ago by christophecvr (christophecvr)

Description: modified (diff)
Version: 2.10.99

comment:2 Changed 7 weeks ago by ryandesign (Ryan Carsten Schmidt)

The "macports user" is intended to be a user account used only by MacPorts. You shouldn't specify your user account or another account that's already used for other things.

comment:3 Changed 7 weeks ago by jmroot (Joshua Root)

Component: portsbase

Also it's not used when not running as root because seteuid doesn't work. We could add some anti-foot-shooting checks. Maybe warn and ignore the --with-macports-user value if --with-no-root-privileges is used, and also reject it if the specified user is a login user?

comment:4 Changed 7 weeks ago by ryandesign (Ryan Carsten Schmidt)

But he didn't use --with-no-root-privileges.

comment:5 in reply to:  3 Changed 7 weeks ago by christophecvr (christophecvr)

Replying to jmroot:

Also it's not used when not running as root because seteuid doesn't work. We could add some anti-foot-shooting checks. Maybe warn and ignore the --with-macports-user value if --with-no-root-privileges is used, and also reject it if the specified user is a login user?

Yes it was just a try of me , My goal with this was to change the build phase user-id which is done by macports with user-id macports.( on it a logic thing since building in general is not supposed to be done with super-user if) Of course the install phase is as root user or at least if the goal is to install in the system paths /usr/local /opt/local and yes in linux systems also /bin /sbin /usr/bin /usr/lib by macos those last are extra protected.

But ok now I know that there is more behind then just that in macports with the consequences ...

I think it's not a bad idea to:

  • mention it in manual
  • the reject if the specified user is a login user, sounds like a good and save idea.
Note: See TracTickets for help on using tickets.