Churchyard (talk | contribs) m (technical description) |
m (spell fix) |
||
(11 intermediate revisions by 2 users not shown) | |||
Line 26: | Line 26: | ||
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. | <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. | ||
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". --> | Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". --> | ||
Changing user PATH '''~/.local/bin''' to be moved to the top of the PATH list instead of the end. This will bring Fedora in sync with other distributions which already fixed this issues (Debian/Ubuntu) and will | Changing user PATH '''~/.local/bin''' and '''~/bin''' to be moved to the top of the PATH list instead of the end. This will bring Fedora in sync with other distributions which already fixed this issues (Debian/Ubuntu) and will make it easier for users to install and use their own command line tools, also fixing multiple bugs where user installed tools cannot be accessed because the system installed ones took precedence. | ||
== Owner == | == Owner == | ||
Line 56: | Line 56: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1595098 #1595098] | ||
* Release Notes tracking: [https://pagure.io/fedora-docs/release-notes/issue/186 #186] | |||
== Detailed Description == | == Detailed Description == | ||
Currently if user is installing | Currently if user is installing their own tools with installers like (pip), they will be installed inside ~/.local/bin or ~/bin but if the same CLI tools are installed at system level the user would not be able to use his own tools because the system one would be picked instead. This happens because .bashrc file adds user PATH to the end instead of the top of PATH list variable. | ||
Same problem was happening with other distributions but they fixed it ([https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839155 Debian bug #83915]) | Same problem was happening with other distributions but they fixed it ([https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839155 Debian bug #83915]) | ||
Line 72: | Line 73: | ||
The issue is not unique to pip installed and applies to any tools that are installed in de facto default XDG folder locations. | The issue is not unique to pip installed and applies to any tools that are installed in de facto default XDG folder locations. | ||
There should be '''no security concerns''' due to this change because any user is already able to add executables and to alter | There should be '''no security concerns''' due to this change because any user is already able to add executables and to alter their own PATH, which means that if someone wants to trick a user to use another executable, they are already able to do that. This has already been proved several times in the [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OXXC5NOZP37W2F6GHV6P5E6K22QHOBNJ/ initial discussions] about this change. | ||
The change itself technically is in <code>/etc/skel/.bash_profile</code> from {{package|bash}}. | The change itself technically is in <code>/etc/skel/.bash_profile</code> from {{package|bash}}. | ||
Line 83: | Line 84: | ||
PATH=$HOME/.local/bin:$HOME/bin:$PATH | PATH=$HOME/.local/bin:$HOME/bin:$PATH | ||
Note that this change will only affect new user accounts, we cannot change PATH for already existing accounts without crazy and undesired hacks. | Note that this change will only affect new user accounts, we cannot change PATH for already existing accounts without crazy and undesired hacks. | ||
Line 92: | Line 91: | ||
This change makes it possible for users to install and use tools at user level, without requiring them to hack their user PATH in order to be able to use them. | This change makes it possible for users to install and use tools at user level, without requiring them to hack their user PATH in order to be able to use them. | ||
This bring Fedora in sync with other major Linux distributions which adopted the same path, | This bring Fedora in sync with other major Linux distributions which adopted the same path, prioritisation. | ||
== Scope == | == Scope == | ||
Line 100: | Line 99: | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Release engineering: [https://pagure.io/releng/ | * Release engineering: [https://pagure.io/releng/issue/7554 #7554] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES --> | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? include a link to the releng issue. | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
Line 125: | Line 124: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== User Experience == | == User Experience == | ||
Line 132: | Line 130: | ||
== Dependencies == | == Dependencies == | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
nope | |||
== Contingency Plan == | == Contingency Plan == | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: (What to do? Who will do it?) | * Contingency mechanism: (What to do? Who will do it?) proposal owners revert the chnage <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: | * Contingency deadline: beta freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? | * Blocks release? no | ||
* Blocks product? | * Blocks product? no | ||
== Documentation == | == Documentation == | ||
Line 151: | Line 147: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
TBD | |||
== Release Notes == | == Release Notes == | ||
Line 160: | Line 156: | ||
--> | --> | ||
Fedora | Fedora now prioritizes commands from <code>$HOME/.local/bin</code> and <code>$HOME/bin</code> over system-wide paths to allow to easily mask system binaries with newer versions. For example <code>pip install --user virtualenv</code> will now work even when virtualenv from the package repositories is installed. The new behavior is only available for newly created user accounts. | ||
* Release Notes tracking: [https://pagure.io/fedora-docs/release-notes/issue/186 #186] | |||
[[Category: | [[Category:ChangeAcceptedF29]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> |
Latest revision as of 12:39, 26 June 2018
User PATH Prioritization
Summary
Changing user PATH ~/.local/bin and ~/bin to be moved to the top of the PATH list instead of the end. This will bring Fedora in sync with other distributions which already fixed this issues (Debian/Ubuntu) and will make it easier for users to install and use their own command line tools, also fixing multiple bugs where user installed tools cannot be accessed because the system installed ones took precedence.
Owner
- Name: Sorin Sbarnea, Till Maas, Miro Hrončok
- Email: ssbarnea@redhat.com, opensource@till.name, mhroncok@redhat.com
- Release notes owner:
Current status
- Targeted release: Fedora 29
- Last updated: 2018-06-26
- Tracker bug: #1595098
- Release Notes tracking: #186
Detailed Description
Currently if user is installing their own tools with installers like (pip), they will be installed inside ~/.local/bin or ~/bin but if the same CLI tools are installed at system level the user would not be able to use his own tools because the system one would be picked instead. This happens because .bashrc file adds user PATH to the end instead of the top of PATH list variable.
Same problem was happening with other distributions but they fixed it (Debian bug #83915)
Example: "pip install --user virtualenv" would install virtualenv at user level, adding ~/.local/bin/virtualenv executable. Still, if virtualenv happens to be installed at system level, this would currently be used instead of user installed one. On the other hand, python itself already knows to prefer user installed modules which means that "python -m virtualenv" will call user installed module instead of the system one.
This may result in undefined behavior, where user installs foo, than run foo, but /usr/bin/foo is run and that import from Python modules in home. Those modules might have different API.
If we change the order and to assure the user folders do take precedence, we would assure that python modules and shell scripts would use the same modules, avoiding weird bugs where what you call is not what you installed.
The issue is not unique to pip installed and applies to any tools that are installed in de facto default XDG folder locations.
There should be no security concerns due to this change because any user is already able to add executables and to alter their own PATH, which means that if someone wants to trick a user to use another executable, they are already able to do that. This has already been proved several times in the initial discussions about this change.
The change itself technically is in /etc/skel/.bash_profile
from bash
.
Currently:
PATH=$PATH:$HOME/.local/bin:$HOME/bin
After the change:
PATH=$HOME/.local/bin:$HOME/bin:$PATH
Note that this change will only affect new user accounts, we cannot change PATH for already existing accounts without crazy and undesired hacks.
Benefit to Fedora
This change makes it possible for users to install and use tools at user level, without requiring them to hack their user PATH in order to be able to use them.
This bring Fedora in sync with other major Linux distributions which adopted the same path, prioritisation.
Scope
- Proposal owners: change
/etc/skel/.bash_profile
to have local folders before the system ones in default PATH
- Other developers: N/A (not a System Wide Change)
- Release engineering: #7554 (a check of an impact with Release Engineering is needed)
- List of deliverables: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
N/A (not a System Wide Change)
How To Test
- pip install --upgrade --user virtualenv
- check that which virtualenv returns ~/.local/bin/virtualenv instead of another value like /usr/bin/virtualenv
There are no risk on breaking current deployments because this change would affect only newly created user accounts and nothing from default system installation would be installing tools at user level.
User Experience
This would bring a huge benefits for Python package creators which avoided promoting user of pip install --user <packagename> for the sole reason that the executable may not be picked. Almost all python tools that are installing CLI utilities do have at least one bug raised by a user that reported that the wrong tool version was used instead.
Dependencies
nope
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) proposal owners revert the chnage
- Contingency deadline: beta freeze
- Blocks release? no
- Blocks product? no
Documentation
TBD
Release Notes
Fedora now prioritizes commands from $HOME/.local/bin
and $HOME/bin
over system-wide paths to allow to easily mask system binaries with newer versions. For example pip install --user virtualenv
will now work even when virtualenv from the package repositories is installed. The new behavior is only available for newly created user accounts.
- Release Notes tracking: #186