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

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

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

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

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?

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).

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

"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"

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.

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

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.

not a gdm bug

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

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.

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

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

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.
>

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?

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.
>

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

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.

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.

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.

"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

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

~/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

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?

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

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

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.

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

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

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

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

:-Dustin

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.

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

One more followup...

This debdiff adds support for fixing this on upgrades.

:-Dustin

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.

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

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.

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