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)
comment:3 follow-up: 5 Changed 7 weeks ago by jmroot (Joshua Root)
Component: | ports → base |
---|
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 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.
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.