#53629 closed defect (fixed)
carthage: Failure during destroot, due to not dropping privs
Reported by: | cbarrett (Colin Barrett) | Owned by: | seanfarley (Sean Farley) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | breun (Nils Breunese), ryandesign (Ryan Carsten Schmidt), raimue (Rainer Müller), bestlem | |
Port: | carthage |
Description
When running sudo port install carthage
:
:notice:destroot ---> Staging carthage into destroot :debug:destroot Can't run destroot under sudo without elevated privileges (due to mtree). :debug:destroot Run destroot without sudo to avoid root privileges. :debug:destroot Going to escalate privileges back to root. :debug:destroot euid changed to: 0. egid changed to: 0.
This causes the call to :info:destroot git submodule update --init --recursive
to fail with, e.g.
:info:destroot Cloning into '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_carthage/carthage/work/Carthage-0.18.1/Carthage/Checkouts/Commandant'... :info:destroot fatal: unable to access 'https://github.com/Carthage/Commandant.git/': SSL certificate problem: Couldn't understand the server certificate format
Sure enough, sandboxing violations like in #50469
default 15:09:52.374632 -0500 kernel SandboxViolation: git-remote-http(70759) deny(1) file-write-data /private/var/db/mds/system/mds.lock
My config doesn't have macportsuser root
in it, or anything like that from the other ticket.
Perhaps whatever's causing ports to run mtree (I haven't looked in detail there yet) should drop privs afterwards? I'm going to keep digging—years and years ago I was a contributor! :)
Attachments (1)
Change History (11)
comment:1 Changed 8 years ago by cbarrett (Colin Barrett)
comment:2 Changed 8 years ago by mf2k (Frank Schima)
Owner: | set to seanfarley |
---|---|
Status: | new → assigned |
Summary: | Failure during destroot, due to not privs → carthage: Failure during destroot, due to not dropping privs |
In the future, please Cc the port maintainers (port info --maintainers carthage
), if any.
comment:3 Changed 8 years ago by seanfarley (Sean Farley)
No idea. Sounds like this happens for any port that does a git clone?
comment:4 Changed 8 years ago by raimue (Rainer Müller)
This report does not make a lot of sense to me and I cannot reproduce the problem. Why would base be fetching with 'git clone' during destroot? There is no indication of that in the port...
Could you provide step by step instructions that show how to reproduce the problem?
Changed 8 years ago by schwerdf (August Schwerdfeger)
Attachment: | CarthageInstall_main.log added |
---|
Log of unsuccessful Carthage install attempt.
comment:5 Changed 8 years ago by schwerdf (August Schwerdfeger)
I am getting a similar error when trying to install Carthage. I ran sudo port install carthage
on an essentially clean installation of MacPorts under Sierra, and it failed on an attempt to clone a Git repository. I have attached the full log from the run.
comment:6 Changed 8 years ago by seanfarley (Sean Farley)
fatal: unable to access 'https://github.com/thoughtbot/Argo.git/': SSL certificate problem: Couldn't understand the server certificate format
... so something is off with certs?
comment:7 Changed 8 years ago by breun (Nils Breunese)
I ran into that error message once and it ended up not having anything to do with certificates. Maybe you've got the same issue: #50469
comment:8 Changed 8 years ago by bestlem
Cc: | bestlem added |
---|
comment:9 Changed 7 years ago by seanfarley (Sean Farley)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Looking at the linked issue, it seems that this is now fixed.
comment:10 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
It will be fixed in MacPorts 2.4.3.
Oops, apologies, the title should be "due to not dropping privs"