[MacPorts] #31827: fetch.type bzr: permission issues due to incorrect ${HOME}
#31827: fetch.type bzr: permission issues due to incorrect ${HOME} ----------------------------------+----------------------------------------- Reporter: ecronin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.0.3 Keywords: | Port: ----------------------------------+----------------------------------------- Ports using fetch.type bzr don't seem to reset ${HOME} to /var/empty before executing the fetch command. This results in bzr trying to read ${home}/.bazaar (warning if it doesn't exist; fatal error if it exists but is unreadable by the macports user) and write ${HOME}/.bzr.log (warning if it can't be written). Unless I move aside ~/.bazaar before installing/upgrading the fetch stage fails because bzr errors out. If I set HOME=/var/empty before running port it succeeds even with ~/.bazaar present. Failure: {{{ [buster] ecronin% ls -ld ~/.bazaar drwx------ 6 ecronin staff 204 Jul 30 21:55 /Users/ecronin/.bazaar/ [buster] ecronin% sudo port clean inkscape-devel ---> Cleaning inkscape-devel [buster] ecronin% sudo port -d fetch inkscape-devel 2>&1 | tail -25 DEBUG: euid/egid changed to: 502/501 DEBUG: Executing proc-pre-org.macports.fetch-fetch-0 ---> Fetching source from bzr repository: this may take a while DEBUG: Executing org.macports.fetch (inkscape-devel) DEBUG: Environment: CPATH='/opt/local/include' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build /_Users_ecronin_Source_macports_dports_graphics_inkscape-devel/inkscape- devel/work/.CC_PRINT_OPTIONS' LIBRARY_PATH='/opt/local/lib' CC_PRINT_OPTIONS='YES' MACOSX_DEPLOYMENT_TARGET='10.7' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build /_Users_ecronin_Source_macports_dports_graphics_inkscape-devel/inkscape- devel/work" && /opt/local/bin/bzr --builtin --no-aliases checkout --lightweight -r 10696 lp:inkscape inkscape-devel-0.48.99.10696' DEBUG: Executing command line: cd "/opt/local/var/macports/build /_Users_ecronin_Source_macports_dports_graphics_inkscape-devel/inkscape- devel/work" && /opt/local/bin/bzr --builtin --no-aliases checkout --lightweight -r 10696 lp:inkscape inkscape-devel-0.48.99.10696 2>&1 failed to open trace file: [Errno 13] Permission denied: '/Users/ecronin/.bzr.log' [85004] 2011-10-29 17:33:59.519 WARNING: You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See "bzr help launchpad- login". You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See "bzr help launchpad- login". bzr: ERROR: Permission denied: "/Users/ecronin/.bazaar/locations.conf": [Errno 13] Permission denied: u'/Users/ecronin/.bazaar/locations.conf' shell command " cd "/opt/local/var/macports/build /_Users_ecronin_Source_macports_dports_graphics_inkscape-devel/inkscape- devel/work" && /opt/local/bin/bzr --builtin --no-aliases checkout --lightweight -r 10696 lp:inkscape inkscape-devel-0.48.99.10696 2>&1" returned error 3 Error: Target org.macports.fetch returned: Bazaar checkout failed DEBUG: Backtrace: Bazaar checkout failed while executing "bzrfetch" (procedure "portfetch::fetch_main" line 11) invoked from within "$procedure $targetname" Warning: the following items did not execute (for inkscape-devel): org.macports.fetch Log for inkscape-devel is at: /opt/local/var/macports/logs /_Users_ecronin_Source_macports_dports_graphics_inkscape-devel/inkscape- devel/main.log Error: Status 1 encountered during processing. To report a bug, see <http://guide.macports.org/#project.tickets> }}} Success: {{{ [buster] ecronin% ls -ld ~/.bazaar drwx------ 6 ecronin staff 204 Jul 30 21:55 /Users/ecronin/.bazaar/ [buster] ecronin% sudo port clean inkscape-devel ---> Cleaning inkscape-devel [buster] ecronin% HOME=/var/empty sudo port -d fetch inkscape-devel 2>&1 | tail -25 DEBUG: Requested variant atlas is not provided by port py27-pyrex. DEBUG: No need to upgrade! py27-pyrex 0.9.9_0 >= py27-pyrex 0.9.9_0 ---> Computing dependencies for inkscape-devel DEBUG: Searching for dependency: bzr DEBUG: Found Dependency: receipt exists for bzr DEBUG: Executing org.macports.main (inkscape-devel) DEBUG: changing euid/egid - current euid: 0 - current egid: 0 DEBUG: egid changed to: 501 DEBUG: euid changed to: 502 DEBUG: fetch phase started at Sat Oct 29 17:34:31 EDT 2011 ---> Fetching inkscape-devel DEBUG: euid/egid changed to: 0/0 DEBUG: chowned /opt/local/var/macports/distfiles/inkscape-devel to macports DEBUG: euid/egid changed to: 502/501 DEBUG: Executing proc-pre-org.macports.fetch-fetch-0 ---> Fetching source from bzr repository: this may take a while DEBUG: Executing org.macports.fetch (inkscape-devel) DEBUG: Environment: CPATH='/opt/local/include' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build /_Users_ecronin_Source_macports_dports_graphics_inkscape-devel/inkscape- devel/work/.CC_PRINT_OPTIONS' LIBRARY_PATH='/opt/local/lib' CC_PRINT_OPTIONS='YES' MACOSX_DEPLOYMENT_TARGET='10.7' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build /_Users_ecronin_Source_macports_dports_graphics_inkscape-devel/inkscape- devel/work" && /opt/local/bin/bzr --builtin --no-aliases checkout --lightweight -r 10696 lp:inkscape inkscape-devel-0.48.99.10696' DEBUG: Executing command line: cd "/opt/local/var/macports/build /_Users_ecronin_Source_macports_dports_graphics_inkscape-devel/inkscape- devel/work" && /opt/local/bin/bzr --builtin --no-aliases checkout --lightweight -r 10696 lp:inkscape inkscape-devel-0.48.99.10696 2>&1 failed to open trace file: [Errno 13] Permission denied: '/var/empty/.bzr.log' [85018] 2011-10-29 17:34:32.547 WARNING: You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See "bzr help launchpad- login". You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See "bzr help launchpad- login". [buster] ecronin% HOME=/var/empty sudo port -d fetch inkscape-devel 2>&1 | tail -25 Password: DEBUG: No need to upgrade! py27-distribute 0.6.24_0 >= py27-distribute 0.6.24_0 DEBUG: epoch: in tree: 0 installed: 0 DEBUG: py27-pyrex 0.9.9_0 exists in the ports tree DEBUG: py27-pyrex 0.9.9_0 is the latest installed DEBUG: py27-pyrex 0.9.9_0 is active DEBUG: Merging existing variants '' into variants DEBUG: new fully merged portvariants: atlas - DEBUG: Changing to port directory: /Users/ecronin/Source/macports/dports/python/py27-pyrex DEBUG: OS darwin/11.2.0 (Mac OS X 10.7) arch i386 DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: Using group file /Users/ecronin/Source/macports/dports/_resources/port1.0/group/python27-1.0.tcl DEBUG: adding the default universal variant DEBUG: Reading variant descriptions from /Users/ecronin/Source/macports/dports/_resources/port1.0/variant_descriptions.conf DEBUG: Requested variant atlas is not provided by port py27-pyrex. DEBUG: No need to upgrade! py27-pyrex 0.9.9_0 >= py27-pyrex 0.9.9_0 ---> Computing dependencies for inkscape-devel DEBUG: Searching for dependency: bzr DEBUG: Found Dependency: receipt exists for bzr DEBUG: Executing org.macports.main (inkscape-devel) DEBUG: changing euid/egid - current euid: 0 - current egid: 0 DEBUG: egid changed to: 501 DEBUG: euid changed to: 502 DEBUG: Skipping completed org.macports.fetch (inkscape-devel) }}} -- Ticket URL: <https://trac.macports.org/ticket/31827> MacPorts <http://www.macports.org/> Ports system for Mac OS
#31827: fetch.type bzr: permission issues due to incorrect ${HOME} ----------------------------------+----------------------------------------- Reporter: ecronin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.0.3 Keywords: | Port: ----------------------------------+----------------------------------------- Comment(by ryandesign@…): Replying to [ticket:31827 ecronin@…]:
Ports using fetch.type bzr don't seem to reset ${HOME} to /var/empty before executing the fetch command.
And this is specific to the bzr fetch type? Where does MacPorts set HOME to /var/empty otherwise? -- Ticket URL: <https://trac.macports.org/ticket/31827#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#31827: fetch.type bzr: permission issues due to incorrect ${HOME} ----------------------------------+----------------------------------------- Reporter: ecronin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.0.3 Keywords: | Port: ----------------------------------+----------------------------------------- Comment(by ecronin@…): It sets the macports user's home directory to /var/empty when it is created. I remember this being an issue with other ports when 2.0 first came out (it was set to /dev/null at first and broke them), and assumed the privilege dropping code now set the environment properly for macportsuser when it is non-root most of the time, just not in this instance. If we aren't setting $HOME to a sanitized value we should be, even when running as root. Building a port shouldn't be creating/modifying files in the user's home directory, and it shouldn't be reading them if we want reproducible builds -- Ticket URL: <https://trac.macports.org/ticket/31827#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#31827: fetch.type bzr: permission issues due to incorrect ${HOME} ----------------------------------+----------------------------------------- Reporter: ecronin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.0.3 Keywords: | Port: ----------------------------------+----------------------------------------- Comment(by ecronin@…): Ticket #30289 for one example where the macports user's $HOME is being picked up instead of the actual user's -- Ticket URL: <https://trac.macports.org/ticket/31827#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#31827: MacPorts should make ${workpath}/home and set HOME to it ----------------------------------+----------------------------------------- Reporter: ecronin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 2.0.3 Keywords: | Port: ----------------------------------+----------------------------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) * milestone: => MacPorts Future Comment: I'm aware there are several tickets now in which ports are forbidden by MacPorts 2's privilege dropping code from writing and sometimes reading items in the user's actual home directory; in these cases we have been modifying the port to set HOME to something inside workpath. I'm not sure why in some cases like #30289 it seems to know what the macports user's home directory is, and in other cases it doesn't. As I said I wasn't aware of MacPorts base actually setting HOME to anything at this time. Perhaps it would be good for MacPorts base to create a directory "${workpath}/home" for every port install and set HOME to that, since that's what we already do manually in some ports (clisp (#31257), parallel (r86242)). Several ports have actually used this in-workpath HOME env var for a lot longer than the privilege dropping code has existed (kmymoney (#24433), the kde and koffice ports (r27011), plplot (r22893), scribus (r19058)) so it may even be a good idea to standardize this for other reasons. -- Ticket URL: <https://trac.macports.org/ticket/31827#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#31827: MacPorts should make ${workpath}/home and set HOME to it ----------------------------------+----------------------------------------- Reporter: ecronin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 2.0.3 Keywords: | Port: ----------------------------------+----------------------------------------- Comment(by ryandesign@…): Since several ports are now making ${workpath}/home manually, when we fix this in MacPorts base, we may want to choose a different location, such as ${workpath}/mphome, to avoid causing a "directory already exists" error with those ports that have already been fixed manually. -- Ticket URL: <https://trac.macports.org/ticket/31827#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
#31827: MacPorts should make ${workpath}/home and set HOME to it ----------------------------------+----------------------------------------- Reporter: ecronin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 2.0.3 Keywords: | Port: ----------------------------------+----------------------------------------- Comment(by jeremyhu@…): Note that we should revert r87905 once this is fixed. -- Ticket URL: <https://trac.macports.org/ticket/31827#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS
#31827: MacPorts should make ${workpath}/home and set HOME to it ----------------------------------+----------------------------------------- Reporter: ecronin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 2.0.3 Keywords: | Port: ----------------------------------+----------------------------------------- Comment(by ecronin@…): Since it looks like we might be ramping up for a new release soon, can we get some sort of fix for this in then? Ryan's suggestion of a per-build ${workpath}/home is probably a more complete solution, but I think just globally setting ${HOME} to /var/empty before spawning any subprocesses would be no more broken than the current situation, and would fix at least 95% of the 'bad' ports without breaking any that currently work. The only ports that actually need ${workpath}/home over an unwritable /var/empty are ones that write to ${HOME} and fail hard if they are unable to do so, and maybe non-standard Portfiles in external port trees that intentionally depend on access to the user's home directory, e.g. to access .svn login info for a private repo. If the port works with read-only access to the user's ${HOME} it should work with read-only access to an empty ${HOME} The full solution would probably be something like a (default empty) ${prefix}/etc/macports/mpuser.skel directory (to allow intentionally tweaking the mpuser's environment) which is copied to ${workpath}/home each time and ${HOME} set to point to that. But just setting ${HOME} to /var/empty is probably a single line change and 5 minutes to the person who already knows the right spot in base to stick that line. -- Ticket URL: <https://trac.macports.org/ticket/31827#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS
#31827: MacPorts should make ${workpath}/home and set HOME to it -----------------------------------+---------------------------------------- Reporter: ecronin@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: MacPorts Future Component: base | Version: 2.0.3 Resolution: fixed | Keywords: Port: | -----------------------------------+---------------------------------------- Changes (by jmr@…): * status: new => closed * resolution: => fixed Comment: r89994 -- Ticket URL: <https://trac.macports.org/ticket/31827#comment:10> MacPorts <http://www.macports.org/> Ports system for Mac OS
#31827: MacPorts should make ${workpath}/home and set HOME to it -----------------------------------+---------------------------------------- Reporter: ecronin@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: MacPorts 2.0.4 Component: base | Version: 2.0.3 Resolution: fixed | Keywords: Port: | -----------------------------------+---------------------------------------- Changes (by jmr@…): * milestone: MacPorts Future => MacPorts 2.0.4 -- Ticket URL: <https://trac.macports.org/ticket/31827#comment:11> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts