Ubuntu

would be nice to add ~/bin to the default PATH

Reported by Gerv on 2006-10-04
54
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gdm (Ubuntu)
Undecided
Unassigned
pam (Ubuntu)
Wishlist
Unassigned

Bug Description

The Alt-F2 "Run Application" dialog runs applications. However, it seems to have a different notion of what the path is to my shells; more specifically, it doesn't include ~/bin, which I have added to the path in both .bash_profile and .bashrc.

So I can't run my Firefox starter script, ~/bin/ff, by pressing Alt-F2 and typing "ff".

This URL:
http://www.ubuntuforums.org/archive/index.php/t-2793.html
has a massively long discussion with at least ten ways to solve the problem. I have no idea which one is best, or "approved", or won't break any upgrades or cause conflicts.

In Dapper, I solved it by putting the following into .gnomerc:
export PATH=$PATH:~/bin
That line is still there, but doesn't seem to be doing the trick any more.

Can someone who understands this stuff please make this work by default? :-)

Related branches

Changed in gnome-panel:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: Unconfirmed → Confirmed
Sebastien Bacher (seb128) wrote :

What version of ubuntu do you use? Using .gnomerc looks like the right way to do. You can also try to edit /etc/environment

Changed in gnome-panel:
status: Confirmed → Needs Info
Gerv (gerv) wrote :

I am using Ubuntu Edgy. I can do either of the things you suggest; however, the point of this bug is that this should work by default, without requiring additional configuration.

Gerv

Sebastien Bacher (seb128) wrote :

You want ~/bin added to the standard path, that's not a gnome-panel problem then

Changed in gnome-panel:
status: Needs Info → Rejected
Gerv (gerv) wrote :

That's not particularly helpful :-| Where should this bug live? I'm afraid I don't know my way around your bug tracking system. Given that you admit it's a reasonable request, can you give some hints as to where to put it?

Jonh Wendell (wendell) wrote :

What Sebastien means is: The problem exists, but it's not gnome-panels's fault. It affects all (or most) gnome softwares.

He (Sebastien) will investigate and tell us how to fix it (or at least where the problem lives).

Sebastien Bacher (seb128) wrote :

We have discussed that on IRC, it doesn't make sense to special case applications for that, if using ~/bin by default makes sense then PATH should list it, that's a change request for pam

Changed in gnome-panel:
assignee: desktop-bugs → nobody
importance: Low → Wishlist
status: Rejected → Confirmed
Jonh Wendell (wendell) wrote :

"would be nice to add ~/bin to the default PATH"

I guess it should be:

"would be nice to add user's PATH to the default PATH"

Gerv (gerv) wrote :

Jonh: you are right, as long as the bug also includes the task "Make sure user's PATH contains ~/bin by default" :-)

My point is that putting personal binaries and scripts in ~/bin is a long-time Unix thing (as far as I am aware) and it should work by default in Ubuntu. I don't see any security or other problems with permitting it.

Toma (tomhaste) wrote :

I find ~/.bin more useful, as i like to keep my GUI/Home clean, and my .bin is still very accessable from the CLI.

Evan Carroll (evancarroll) wrote :

I think ~/.bin is silly, however I'm having the problem now with ~/bin ( git (from source) installs to ~/bin, and the version in the feisty repos is old. ).. Currently I'm confused on this matter, as ~/.bash_profile ( by proxy of /etc/skel/.bash_profile) contains

# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
    PATH=~/bin:"${PATH}"
fi

Which applies for all login shells and subprocs that are initiated through a bash login. Now while I haven't tested this, this should mean that the bug is in fact in G/K/X-DM. If $PATH is changed, all subshells (forks etc) should inherit the modified $PATH variable. As long as that method's login-script has a stanza like the above.

If your login shell, or parent process is GDM/KDM then a non-existent-bash-login won't execute the bash-login-shell script ~/.bash_profile. This is a failed assumption by someone possibly years old.

The proof would be to shutdown gdm/gnome, login through a term (bash -l shell), call gnome manually and echo $PATH; ~/bin should be there.

A patch is supplied for gdm:
root@x60s:/etc/gdm/Init# diff Default new-Default -c1
*** Default 2006-10-20 18:36:24.000000000 -0500
--- new-Default 2007-05-17 11:47:10.000000000 -0500
***************
*** 5,7 ****

! PATH=/usr/X11R6/bin:$PATH
  OLD_IFS=$IFS
--- 5,7 ----

! PATH=~/bin:/usr/X11R6/bin:$PATH
  OLD_IFS=$IFS

Please move this bug to gdm, apply the patch, mark as resolved, and give to the kubuntu guys so they can fix kdm too.

Sebastien Bacher (seb128) wrote :

not a gdm bug

Changed in gdm:
status: Unconfirmed → Rejected
Sebastien Bacher (seb128) wrote :

as explained previous gdm is not the right place to change the PATH, that should be done from pam

Evan Carroll (evancarroll) wrote :

Ok so everyone is for doing this pam, I found a (slightly) better place to do this than gdm anyway. Someone should make note if this is done in pam to remove the related lines in ~/.bash_profile too. I applied a patch instead of to gdm, too: /etc/X11/Xsession.d/99x11-common_start

ecarroll@x60s:/etc/X11/Xsession.d$ diff 99x11-common_start 99x11-common_start2 -c1
*** 99x11-common_start 2007-05-17 13:58:52.000000000 -0500
--- 99x11-common_start2 2007-05-17 13:59:05.000000000 -0500
***************
*** 4,5 ****
--- 4,10 ----

+ # set PATH so it includes user's private bin if it exists
+ if [ -d ~/bin ] ; then
+ PATH=~/bin:"${PATH}"
+ fi
+
  exec $STARTUP

I chose to patch this into /etc/X11/Xsession.d/99x11-common_start because that way it would work despite what graphical login shell was used.

This works perfectly, and can be used as a fix until someone hacks a patch into pam.

Evan Carroll (evancarroll) wrote :

Anyone want to start a donation pot to get this fixed?

Jerome Haltom (wasabi) wrote :

I would like to suggest to point everybody to a feature request that describes how this SHOULD be implemented:

https://bugs.launchpad.net/ubuntu/+source/pam/+bug/145380

Jerome Haltom (wasabi) wrote :

This is doable on a per-user level by creating a ~/.pam_environment variable which is processed during login. This is the appropiate place to put environmental variables such as this.

Would it be feasable then to add an option to set a home based
exectutable path in the User and Groups dialog?

On 21/11/2007, Jerome Haltom <email address hidden> wrote:
> This is doable on a per-user level by creating a ~/.pam_environment
> variable which is processed during login. This is the appropiate place
> to put environmental variables such as this.
>
> --
> would be nice to add ~/bin to the default PATH
> https://bugs.launchpad.net/bugs/64064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Jason Toffaletti (jason) wrote :

I'm taking a stab at resolving this and #145380. Some questions came up after discussion in #ubuntu-motu:

1) Do we really want ~/bin in the PATH by default?
If so, should this be done in /etc/environment or /etc/skel/.pam_environment?
If not, we should get rid of it being added conditionally in /etc/skel/.profile?

2) If we don't want it by default when would we consider this resolved if there was a UI in Users & Groups to add it to ~/.pam_environment?

Toma (tomhaste) wrote :

The later sounds better. It would the user knows they want it there
and has an easy way of setting it up. Whereas the first option makes
it default across all the board.

It would again be nice to have a choice on what the folder is called
aswell. I have ~/.bin to hide all my little scripts since I dont need
to see them, I just want to run them.

Toma-

On 16/01/2008, Jason Toffaletti <email address hidden> wrote:
> I'm taking a stab at resolving this and #145380. Some questions came up
> after discussion in #ubuntu-motu:
>
> 1) Do we really want ~/bin in the PATH by default?
> If so, should this be done in /etc/environment or /etc/skel/.pam_environment?
> If not, we should get rid of it being added conditionally in /etc/skel/.profile?
>
> 2) If we don't want it by default when would we consider this resolved
> if there was a UI in Users & Groups to add it to ~/.pam_environment?
>
> --
> would be nice to add ~/bin to the default PATH
> https://bugs.launchpad.net/bugs/64064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Gerv (gerv) wrote :

Jason: are there any risks to having ~/bin in the PATH by default? If not, why not? It's the traditional Unix place for people to put their own scripts. If people don't want it, they just don't create the directory. If people want some other directories, they can add them too in the way I have, or in a more convenient way to be developed.

It also seems to me that adding it unconditionally (or perhaps, conditionally on its actually existing), in whatever file you consider appropriate, is the easiest way to resolve this bug. If someone has to add UI to Users and Groups, isn't that going to take much longer and be much more effort?

Gerv

John Dong (jdong) wrote :

There are risks -- users can add in-path executables to the system, making it easier for an exploit to be leashed against the user. A malicious script can install a bunch of tools under similar names to existing commands (i.e. ks instead of ls) so that the next time the user types that on accident, something bad happens.

Of course, if a program has been compromised enough to let this happen, then this should be the LEAST of your concerns ;-)

I would personally like to see this configurable and not enabled by default, as it's not really standard practice on any distro currently and not everyone would like it.

Evan Carroll (evancarroll) wrote :

I want to see it the default -- and your argument either makes no sense, or is so contrived as to be near useless. At least you disclaim the usefulness in the same response.

The first question you should ask, is what script can install with +x (so you can mistakingly execute them) and not just execute them itself? The home directory is owned, and grouped by the respective user of the directory by default. A non-user, non-group can only read files in home. So to install the files in ~/bin, you must be the USER or root. If a malicious script installs the files, presumably it has the user's permission, and after the permission level is compromised no amount of tomfoolery can make it all that much worse.

Sven Boden (svenboden) wrote :

Setting it as default is a bit harsh. Why put ~bin in by default, and not e.g. ~shs.

Anyway bug tracker https://bugs.launchpad.net/ubuntu/+source/pam/+bug/145380 solves the problem in a nice way by allowing users to set it, which makes setting it by default a bit moot: new users won't miss it, advanced user can do a one-time change.

Gerv (gerv) wrote :

"Setting it as default is a bit harsh. Why put ~bin in by default, and not e.g. ~shs."

Because ~/bin has been the home for a user's personal binaries since the early days of Unix.

What does "shs" stand for, anyway?

Gerv

Sven Boden (svenboden) wrote :

shs=shellscripts... another convention used in some unix environment systems. Just to point out that ~bin is not universal.

Evan Carroll (evancarroll) wrote :

~/bin is most definitely universal; google hasn't even heard of your
~/shs. Not to mention there would be no reason to make it an
executable-directory specific to the contents of the executable. It
would be rather counter-unixey.

Case and point, - git installs to ~/bin. Half of the files are
scripts; the other half are executables.

On 3/19/08, Sven Boden <email address hidden> wrote:
> shs=shellscripts... another convention used in some unix environment
> systems. Just to point out that ~bin is not universal.
>
>
> --
> would be nice to add ~/bin to the default PATH
> https://bugs.launchpad.net/bugs/64064
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Evan Carroll
System Lord of the Internets

Martin Franco (mfranco-gmx) wrote :

Looks to me like ~/bin should be added to /etc/environment. pam_env reads that by default, and that's where PATH is set.
dpkg-query -S /etc/environment couldn't find the originating package. does pam create it?

Morten Kjeldgaard (mok0) wrote :

The file /etc/environment is created by libpam-modules.postinst

Kees Cook (kees) wrote :

This may cause issues for people logging in on network filesystems in /home. Similar problems were seen with the ~/.pam_environment patches.

Evan Carroll (evancarroll) wrote :

In order for this to be a problem, the networked file system would have to have a ~/bin created. If someone has a ~/bin created and they're relying on it not being added to PATH= they kinda deserve it.

Dustin Kirkland  (kirkland) wrote :

Hey Kees-

I must admit that I don't entirely grasp the scope of the issue you're raising with /home living on a networked filesystem (sorry).

 * Is your concern a security one, where a malicious user gaining access to the network file server could potentially inject badness in various users ~/bin?
 * Or is it a performance concern, in that we're adding a search in PATH on a remote filesystem?
 * ...?

In the mean time, I have a simple, one-line patch that adds ~/bin to the end of the initial PATH definition in /etc/environment.

Depending on Kees' explanation of his concerns, I can add some additional logic to libpam-modules.postinst to affirm that no user's ~bin is on a networked filesystem at /etc/environment creation time.

:-Dustin

Dustin Kirkland  (kirkland) wrote :

I have tested my patch.

It works well with:
 * bash
 * dash
 * ksh
 * ash

But does not work with:
 * zsh
 * csh
 * fish
 * tcsh
 * es
 * rc
 * sash

I did not see any ill-effects on the shells where it didn't work, besides not finding executables in ~/bin. And I think we have the vast majority of Ubuntu's shell users covered with (bash, dash, ksh, ash).

:-Dustin

Dustin Kirkland  (kirkland) wrote :

My patch also works with:
 * Gnome + Alt-F2
 * XFCE + Alt-F2
 * KDE

This provides the desired behavior covers the main Ubuntu desktop managers, and the Bourne-compatible shells (dash, bash, ash, ksh) and would benefit the majority of [K/X/U]buntu users.

It does *not* break functionality on non-Bourne shells. Users of these shells will need to update their ~/.pam_environment or other .*rc scripts to add a fully qualified /home/user/bin to the PATH environment variable. Or, actually just:
    eval PATH="$PATH"
as the problem seems to be that non-Bourne shells do not evaluate the ~ or the $HOME variables in the PATH declaration.

Proposing for sponsorship for Intrepid.

:-Dustin

Dustin Kirkland  (kirkland) wrote :

Marking in progress, assigning to myself since I tested/submitted a patch, targeting Intrepid.

:-Dustin

Changed in pam:
assignee: nobody → kirkland
milestone: none → ubuntu-8.10-beta
status: Confirmed → In Progress
Bryce Harrington (bryce) wrote :

Thanks, uploaded.

Checking Signature on .changes
gpg: Signature made Thu Jun 19 21:15:53 2008 PDT using DSA key ID E0E67611
gpg: Good signature from "Bryce Harrington <email address hidden>"
gpg: aka "Bryce Harrington <email address hidden>"
gpg: aka "Bryce Harrington <email address hidden>"
gpg: aka "Bryce Harrington <email address hidden>"
gpg: aka "Bryce Harrington <email address hidden>"
Good signature on /home/bryce/src/Merges/pam/pam_0.99.7.1-5ubuntu8_source.changes.
Checking Signature on .dsc
gpg: Signature made Thu Jun 19 21:15:50 2008 PDT using DSA key ID E0E67611
gpg: Good signature from "Bryce Harrington <email address hidden>"
gpg: aka "Bryce Harrington <email address hidden>"
gpg: aka "Bryce Harrington <email address hidden>"
gpg: aka "Bryce Harrington <email address hidden>"
gpg: aka "Bryce Harrington <email address hidden>"
Good signature on /home/bryce/src/Merges/pam/pam_0.99.7.1-5ubuntu8.dsc.
Uploading to ubuntu (via ftp to upload.ubuntu.com):
  pam_0.99.7.1-5ubuntu8.dsc: done.
  pam_0.99.7.1-5ubuntu8.diff.gz: done.
  pam_0.99.7.1-5ubuntu8_source.changes: done.
Successfully uploaded packages.
Not running dinstall.

Changed in pam:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pam - 0.99.7.1-5ubuntu8

---------------
pam (0.99.7.1-5ubuntu8) intrepid; urgency=low

  * debian/libpam-modules.postinst: Add ~/bin to the end of the default PATH
    set in /etc/environment (LP: #64064).

 -- Dustin Kirkland <email address hidden> Thu, 19 Jun 2008 12:52:48 -0500

Changed in pam:
status: Fix Committed → Fix Released
Dustin Kirkland  (kirkland) wrote :

One more followup...

This debdiff adds support for fixing this on upgrades.

:-Dustin

Jamie Strandboge (jdstrand) wrote :

Reverted patch. As pointed out by Colin Watson on IRC, adding ~/bin to /etc/environment does not work consistently, which makes this patch only a partial fix, and confusing for end users. For example, in addition to the shells mentioned by Dustin, anything that uses getenv() (such as execlp()) will not properly expand '~'. It is suggested (again by Colin), that the various paths into the system (such as login, ssh, *dm, etc) be studied so a proper solution can be found.

Changed in pam:
status: Fix Released → Confirmed
Dustin Kirkland  (kirkland) wrote :

Removing myself as assignee.

I grabbed this bug long ago, when it was tagged "bite size". I created a fix that solved this problem for some shells, and in some cases (where ~ is expanded properly). However, that fix was reverted in that the solution was only partial, and incomplete.

I don't really intend on returning to work on this bug. Sorry.

:-Dustin

Changed in pam (Ubuntu):
milestone: ubuntu-8.10-beta → none
assignee: Dustin Kirkland (kirkland) → nobody
Drew (drewwells) wrote :

Th e problem is not users adding system paths, the problem is gnome-panel allows no user overrides. The only way to modify the path is to modify the global /etc/profile. Gnome-panel should be overridden by ~/.profile.

Drew (drewwells) wrote :

I should update, /etc/profile doesn't work. ~/.gnomerc does obliging my concerns of modifying global env variables for local settings.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers