PATH has /bin before /usr/bin in upgraded rawhide

[Sandro Mani]

Hi,

I just noticed that my rawhide installation, which was originally 
installed when F18 was rawhide in summer 2012 and upgraded since, has

PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin

On a fresh rawhide installation, I get

PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin

So, the order of /bin /usr/bin /usr/local/bin is reversed. Who is 
screwing up the order?
- /etc/profile, /etc/bashrc and /etc/profile.d/* are identical between 
the "old" and the "new" installations
- strings /bin/bash | grep /bin gives me the same output in both cases
- my .bashrc and .bash_profile are harmless (i.e. 
PATH=$PATH:$HOME/.local/bin:$HOME/bin)

Any ideas?

Thanks!

Sandro

[Reindl Harald]

Am 27.10.2013 01:10, schrieb Sandro Mani:
>  I just noticed that my rawhide installation, which was originally
> installed when F18 was rawhide in summer 2012 and
>  upgraded since, has
>  
>
> PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
>  
>  On a fresh rawhide installation, I get
>  
>
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
>  
>  So, the order of /bin /usr/bin /usr/local/bin is reversed 
besides the fact that /bin and /sbin should *not* be anywhere in the
path over the whole distribution after the UsrMove in F17
/usr/local/bin before /usr/bin is the correct order because of the
intention of /usr/local

http://fedoraproject.org/wiki/Features/UsrMove
so why is there /bin these days in any path?

[Sandro Mani]

On 27.10.2013 01:38, Reindl Harald wrote:
>  Am 27.10.2013 01:10, schrieb Sandro Mani:
> > I just noticed that my rawhide installation, which was originally installed when F18
> was rawhide in summer 2012 and
> > upgraded since, has
> >
> >
> PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
> >
> > On a fresh rawhide installation, I get
> >
> >
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
> >
> > So, the order of /bin /usr/bin /usr/local/bin is reversed
>  besides the fact that /bin and /sbin should *not* be anywhere in the
>  path over the whole distribution after the UsrMove in F17
>  /usr/local/bin before /usr/bin is the correct order because of the
>  intention of /usr/local 
I actually have /usr/bin *before* /usr/local/bin
>  http://fedoraproject.org/wiki/Features/UsrMove
>  so why is there /bin these days in any path?
>
>
>

[Reindl Harald]

Am 27.10.2013 01:41, schrieb Sandro Mani:
>  On 27.10.2013 01:38, Reindl Harald wrote:
> > Am 27.10.2013 01:10, schrieb Sandro Mani:
> >> I just noticed that my rawhide installation, which was originally installed when
> F18 was rawhide in summer 2012 and
> >> upgraded since, has
> >>
> >>
> PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
> >>
> >> On a fresh rawhide installation, I get
> >>
> >>
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
> >>
> >> So, the order of /bin /usr/bin /usr/local/bin is reversed
> > besides the fact that /bin and /sbin should *not* be anywhere in the
> > path over the whole distribution after the UsrMove in F17
> > /usr/local/bin before /usr/bin is the correct order because of the
> > intention of /usr/local
>  I actually have /usr/bin *before* /usr/local/bin 
your first post is unclear because you speak about two setups
to get rid of all this UsrMove fragments make a strict config

the way below it affects interactive as wella s non-interactive shells
and overrides even the openssh/bash builtin paths which was buggy
not so lnog ago or maybe still are

[harry@srv-rhsoft:~]$ cat /home/harry/.bashrc | grep PATH
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/harry/bin

[harry@srv-rhsoft:~]$ cat /home/harry/.bash_profile | grep PATH
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/harry/bin

[harry@srv-rhsoft:~]$ cat /etc/crontab | grep PATH
PATH=/usr/sbin:/usr/bin

[harry@srv-rhsoft:~]$ cat /etc/anacrontab | grep PATH
PATH=/usr/sbin:/usr/bin

[Sandro Mani]

>  your first post is unclear because you speak about two setups
>  to get rid of all this UsrMove fragments make a strict config
>
>  
Ah yes, I could have expressed it better. My problem is the following:

[sandro@oldrawhide]$ echo $PATH
/bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin

[sandro@newrawhide]$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin



So, to write it clearly: I didn't change or play with any PATH settings 
anywhere, on neither of the two machines. My problem is that I cannot 
find who is causing the paths on my "oldrawhide" machines to be 
different from those of my "newrawhide".

Hope this is clearer.

Sandro

[Michael Schwendt]

On Sun, 27 Oct 2013 02:00:17 +0200, Sandro Mani wrote:

>  
>  > your first post is unclear because you speak about two setups
>  > to get rid of all this UsrMove fragments make a strict config
>  >
>  >
>  
>  Ah yes, I could have expressed it better. My problem is the following:
>  
>  [sandro@oldrawhide]$ echo $PATH
>
> /bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
>  
>  [sandro@newrawhide]$ echo $PATH
>
> /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
>
>  
>  
>  So, to write it clearly: I didn't change or play with any PATH settings 
>  anywhere, on neither of the two machines. My problem is that I cannot 
>  find who is causing the paths on my "oldrawhide" machines to be 
>  different from those of my "newrawhide". 
In which places have you searched already?
Is it the same for a fresh user account?
Is it the same for "root"?
Is the "setup" package unmodified?
Is it specific to "bash" or also other shells (such as "tcsh")?

/home/sandro/.local/bin in the PATH is not the default.
Or is it new for Rawhide?

[Frank Murphy]

On Sun, 27 Oct 2013 14:59:33 +0100
Michael Schwendt <mschwendt(a)gmail.com&gt; wrote:


>  /home/sandro/.local/bin in the PATH is not the default.
>  Or is it new for Rawhide? 
This in in F20 for me as user:
~$ echo $PATH
<snip>.../home/frank/.local/bin:/home/frank/bin

so the bit with the name seems to be branched at least


-- 
Regards,
Frank 
www.frankly3d.com

[Sandro Mani]

>  In which places have you searched already? 
$HOME/.bashrc
$HOME/.bash_profile
/etc/bashrc
/etc/profile
/etc/profile.d/*
>  Is it the same for a fresh user account?
>  Is it the same for "root"? 
Logging in from a VT as root resp. newly
created user test I get

[root@oldrawhide]# echo $PATH
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
# -> chaos

[test@oldrawhide]$ echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/test/.local/bin:/home/test/bin
# -> /bin:/usr/bin inverted, otherwise ok

>  Is the "setup" package unmodified? 
yes (reinstalled
just to be sure)
>  Is it specific to "bash" or also other shells (such as
> "tcsh")? 
Also tcsh is affected (changed login shell in /etc/passwd and
logged in 
from VT)
>  /home/sandro/.local/bin in the PATH is not the default.
>  Or is it new for Rawhide? 
P.s.: I know some people like easter eggs, but please, don't 
exaggerate... http://smani.fedorapeople.org/screenshot.jpg (no, I did 
not rotate the image)

[Michael Schwendt]

On Sun, 27 Oct 2013 15:43:44 +0100, Sandro Mani wrote:

>  > In which places have you searched already?
>  $HOME/.bashrc
>  $HOME/.bash_profile
>  /etc/bashrc
>  /etc/profile
>  /etc/profile.d/*
>  > Is it the same for a fresh user account?
>  > Is it the same for "root"?
>  Logging in from a VT as root resp. newly created user test I get
>  
>  [root@oldrawhide]# echo $PATH
>  /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
>  # -> chaos 
Chaos? That output looks normal and has been like that for years.

>  [test@oldrawhide]$ echo $PATH
>
> /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/test/.local/bin:/home/test/bin
>  # -> /bin:/usr/bin inverted, otherwise ok 
My Rawhide is broken, so I cannot check whether this is reproducible
and specific to Rawhide (e.g. via the path munging in /etc/profile).
A little bit debugging output (even simply printing $PATH to a file)
in the bash config files might lead to something already.

[Sandro Mani]

On 28.10.2013 11:11, Michael Schwendt wrote:
>  On Sun, 27 Oct 2013 15:43:44 +0100, Sandro Mani wrote:
>
> >> In which places have you searched already?
> > $HOME/.bashrc
> > $HOME/.bash_profile
> > /etc/bashrc
> > /etc/profile
> > /etc/profile.d/*
> >> Is it the same for a fresh user account?
> >> Is it the same for "root"?
> > Logging in from a VT as root resp. newly created user test I get
> >
> > [root@oldrawhide]# echo $PATH
> > /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
> > # -> chaos
>  Chaos? That output looks normal and has been like that for years. 
Oh yeah sorry,
true. (I had expected 
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/root/bin). 
But I wonder, why is /bin before /usr/bin here? It makes i.e. 
AC_PATH_PROG fail miserably for many old-style autoconf scripts which 
use this to determine the prefix. (Though agreed, you usually do not 
compile things as root).
> > [test@oldrawhide]$ echo $PATH
> >
> /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/test/.local/bin:/home/test/bin
> > # -> /bin:/usr/bin inverted, otherwise ok
>  My Rawhide is broken, so I cannot check whether this is reproducible
>  and specific to Rawhide (e.g. via the path munging in /etc/profile).
>  A little bit debugging output (even simply printing $PATH to a file)
>  in the bash config files might lead to something already. 
On both the oldrawhide
and newrawhide machines, adding echo $PATH > 
/tmp/path as the first line in /etc/bashrc and /etc/profile, /bin is 
before /usr/bin.
- add line to /etc/bashrc, cat /tmp/path gives
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin
- add line to /etc/profile, cat /tmp/path gives
/usr/local/bin:/bin:/usr/bin

The odd thing I didn't notice before is that on a VT, also on the 
newrawhide machine (as non-root user) I get 
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/$HOME/.local/bin:$HOME/bin. 
But from a GUI terminal, /bin and /usr/bin are in inverted order (i.e. 
/usr/bin before /bin, as expected). Can anyone else reproduce this?

Thanks,
SAndro

[Ben Boeckel]

On Mon, 28 Oct, 2013 at 11:02:56 GMT, Sandro Mani wrote:
>  The odd thing I didn't notice before is that on a VT, also on the
>
>  newrawhide machine (as non-root user) I get 
>  /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/$HOME/.local/bin:$HOME/bin. 
>  But from a GUI terminal, /bin and /usr/bin are in inverted order (i.e. 
>  /usr/bin before /bin, as expected). Can anyone else reproduce this? 
I'm able to reproduce the error on my Rawhide box (last installed as
Fedora 18/Rawhide in July 2012) on a TTY:

    $ echo $PATH
   
/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/boeckb/.cabal/bin

My bashrc fixes it to:

    % echo $PATH
   
/home/boeckb/.local/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/boeckb/.cabal/bin:/home/boeckb/bin

The code which does this:

    # Fix PATH
    _fix_path () {
        local old_path
        local tr
        local readlink

        old_path="$PATH"
        tr="$( which tr )"
        readlink="$( which readlink )"

        PATH="$HOME/.local/bin"

        for p in $( echo "$old_path" | "$tr" ":" "
" ); do
            [ -d "$p" ] && \
            #[ "$p" = "${p#/usr/local}" ] && \
            [ -z "$( "$readlink" "$p" )" ] && \
                PATH="$PATH${PATH:+:}$p"
        done

        export PATH
    }

    _fix_path

    unset _fix_path

Not sure where $HOME/bin comes from. And yeah, I put $HOME/.local/bin
first. I have wrapper scripts which trampoline a few things and link to
my local install root (~/misc/root/$pkg) for local versions of things
like task, mpv, sometimes git, and others).

--Ben

$HOME/.local/bin in $PATH

[Michael Schwendt]

>  /home/sandro/.local/bin in the PATH is not the default.
>  Or is it new for Rawhide? 
$ grep PATH /etc/skel/.bash_profile 
PATH=$PATH:$HOME/.local/bin:$HOME/bin
export PATH

Exists for a longer time already, added in of the .fc16 builds:

* Tue Jun 07 2011 Roman Rakus <…> - 4.2.10-3
- Added $HOME/.local/bin to PATH in .bash_profile (#699812)

One must not overwrite $HOME/.bash_profile, of course. ;-)

$HOME/.local/bin in $PATH

[Paul Wouters]

On Mon, 28 Oct 2013, Michael Schwendt wrote:

> > /home/sandro/.local/bin in the PATH is not the default.
> > Or is it new for Rawhide?
>
>  $ grep PATH /etc/skel/.bash_profile
>  PATH=$PATH:$HOME/.local/bin:$HOME/bin
>  export PATH
>
>  Exists for a longer time already, added in of the .fc16 builds:
>
>  * Tue Jun 07 2011 Roman Rakus <…> - 4.2.10-3
>  - Added $HOME/.local/bin to PATH in .bash_profile (#699812) 
An invisible directory in everyone's PATH. That's rather unfortunate.

When will this be removed?

Paul

$HOME/.local/bin in $PATH

[Sérgio Basto]

On Seg, 2013-10-28 at 11:28 -0400, Paul Wouters wrote: 
>  On Mon, 28 Oct 2013, Michael Schwendt wrote:
>  
>  >> /home/sandro/.local/bin in the PATH is not the default.
>  >> Or is it new for Rawhide?
>  >
>  > $ grep PATH /etc/skel/.bash_profile
>  > PATH=$PATH:$HOME/.local/bin:$HOME/bin
>  > export PATH
>  >
>  > Exists for a longer time already, added in of the .fc16 builds:
>  >
>  > * Tue Jun 07 2011 Roman Rakus <…> - 4.2.10-3
>  > - Added $HOME/.local/bin to PATH in .bash_profile (#699812)
>  
>  An invisible directory in everyone's PATH. That's rather unfortunate.
>  
>  When will this be removed? 
I agree, I don't have $HOME/.local/bin directory , but bug #699812 ,have
request the opposite ... , I don't see any good reason there but ...   

Best regards,
-- 
Sérgio M. B.

$HOME/.local/bin in $PATH

[Alec Leamas]

On 10/28/2013 07:08 PM, Sérgio Basto wrote:
>  On Seg, 2013-10-28 at 11:28 -0400, Paul Wouters wrote:
> > On Mon, 28 Oct 2013, Michael Schwendt wrote:
> >
> >>> /home/sandro/.local/bin in the PATH is not the default.
> >>> Or is it new for Rawhide?
> >> $ grep PATH /etc/skel/.bash_profile
> >> PATH=$PATH:$HOME/.local/bin:$HOME/bin
> >> export PATH
> >>
> >> Exists for a longer time already, added in of the .fc16 builds:
> >>
> >> * Tue Jun 07 2011 Roman Rakus <…> - 4.2.10-3
> >> - Added $HOME/.local/bin to PATH in .bash_profile (#699812)
> > An invisible directory in everyone's PATH. That's rather unfortunate.
> >
> > When will this be removed?
>  I agree, I don't have $HOME/.local/bin directory , but bug #699812 ,have
>  request the opposite ... , I don't see any good reason there but ...
>
>  Best regards, 
Deja vú: 
https://lists.fedoraproject.org/pipermail/devel/2011-July/154896.html

$HOME/.local/bin in $PATH

[Michael Schwendt]

On Mon, 28 Oct 2013 19:44:23 +0100, Alec Leamas wrote:

>  Deja vú: 
>  https://lists.fedoraproject.org/pipermail/devel/2011-July/154896.html 
Hah! A thread of doom.

[...]

Does any software store files into $HOME/.local/bin/ yet?

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 28.10.2013 19:51, schrieb Michael Schwendt:
>  On Mon, 28 Oct 2013 19:44:23 +0100, Alec Leamas wrote:
>  
> > Deja vú: 
> > https://lists.fedoraproject.org/pipermail/devel/2011-July/154896.html
>  
>  Hah! A thread of doom.
>  
>  [...]
>  
>  Does any software store files into $HOME/.local/bin/ yet? 
not that i know because the directory does not exist here
even if: this crap needs to be fixed, binaries in hidden
folders are bad by definition

$HOME/.local/bin in $PATH

[Michael Ekstrand]

On Mon, 28 Oct 2013 19:51:06 +0100
Michael Schwendt <mschwendt(a)gmail.com&gt; wrote:

>  On Mon, 28 Oct 2013 19:44:23 +0100, Alec Leamas wrote:
>  
>  > Deja vú: 
>  > https://lists.fedoraproject.org/pipermail/devel/2011-July/154896.html
>  
>  Hah! A thread of doom.
>  
>  [...]
>  
>  Does any software store files into $HOME/.local/bin/ yet? 
Yes.

pip install --user <some python package>

The pip user scheme is to use ~/.local as an FHS-ish thing. IMO, this
is much superior to the cabal, gem, etc. notion that they should each
have their own bin directory for user-installed programs.

- Michael

-- 
Michael Ekstrand — http://elehack.net/

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 28.10.2013 20:00, schrieb Michael Ekstrand:
>  On Mon, 28 Oct 2013 19:51:06 +0100
>  Michael Schwendt <mschwendt(a)gmail.com&gt; wrote:
>  
> > On Mon, 28 Oct 2013 19:44:23 +0100, Alec Leamas wrote:
> >
> >> Deja vú: 
> >> https://lists.fedoraproject.org/pipermail/devel/2011-July/154896.html
> >
> > Hah! A thread of doom.
> >
> > [...]
> >
> > Does any software store files into $HOME/.local/bin/ yet?
>  
>  Yes.
>  
>  pip install --user <some python package>
>  
>  The pip user scheme is to use ~/.local as an FHS-ish thing. IMO, this
>  is much superior to the cabal, gem, etc. notion that they should each
>  have their own bin directory for user-installed programs 
the they should use ~/local or whatever
but using a hidden dir for binaries should be prohibited
besides that user-writeable binaries are bad for security resons too

$HOME/.local/bin in $PATH

[Michael Schwendt]

On Mon, 28 Oct 2013 14:00:54 -0500, Michael Ekstrand wrote:

>  > Does any software store files into $HOME/.local/bin/ yet?
>  
>  Yes.
>  
>  pip install --user <some python package>
>  
>  The pip user scheme is to use ~/.local as an FHS-ish thing. IMO, this
>  is much superior to the cabal, gem, etc. notion that they should each
>  have their own bin directory for user-installed programs. 
That's scary stuff for a distribution like Fedora!
It even overrides (!) Python's search path for Modules:

> >> import sys
> >> print sys.path 
['', '/usr/lib64/python27.zip',
'/usr/lib64/python2.7', '/usr/lib64/python2.7/plat-linux2',
'/usr/lib64/python2.7/lib-tk', '/usr/lib64/python2.7/lib-old',
'/usr/lib64/python2.7/lib-dynload',
'/home/ms/.local/lib/python2.7/site-packages',
'/usr/lib64/python2.7/site-packages',
'/usr/lib64/python2.7/site-packages/gst-0.10',
'/usr/lib64/python2.7/site-packages/gtk-2.0',
'/usr/lib/python2.7/site-packages']

$HOME/.local/bin in $PATH

[Sérgio Basto]

On Seg, 2013-10-28 at 14:00 -0500, Michael Ekstrand wrote:
>  > Does any software store files into $HOME/.local/bin/ yet?
>  
>  Yes.
>  
>  pip install --user <some python package>
>  
>  The pip user scheme is to use ~/.local as an FHS-ish thing. IMO, this
>  is much superior to the cabal, gem, etc. notion that they should each
>  have their own bin directory for user-installed programs. 
Hi, I have pip in Debian servers (old and new release) and in Fedora,
and don't find any .local/bin 
So my argument is more , nobody and noapp put things in ~/.local/bin 

and where is xdg recommendation to use .local/bin ? I goggling it and
don't find any reference to that . 


-- 
Sérgio M. B.

$HOME/.local/bin in $PATH

[Michael Ekstrand]

On Mon, 28 Oct 2013 20:30:05 +0000
Sérgio Basto <sergio(a)serjux.com&gt; wrote:

>  On Seg, 2013-10-28 at 14:00 -0500, Michael Ekstrand wrote:
>  > > Does any software store files into $HOME/.local/bin/ yet?
>  > 
>  > Yes.
>  > 
>  > pip install --user <some python package>
>  > 
>  > The pip user scheme is to use ~/.local as an FHS-ish thing. IMO,
>  > this is much superior to the cabal, gem, etc. notion that they
>  > should each have their own bin directory for user-installed
>  > programs.
>  
>  Hi, I have pip in Debian servers (old and new release) and in Fedora,
>  and don't find any .local/bin 
>  So my argument is more , nobody and noapp put things in ~/.local/bin  
Fedora 19:

$ pip install --user --upgrade mercurial
$ ls ~/.local/bin/hg
/home/michael/.local/bin/hg

So, if you use 'pip install --user' to install a Python module that
provides scripts/executables, it will by default put those executables
in ~/.local/bin.

>  and where is xdg recommendation to use .local/bin ? I goggling it
> and
>  don't find any reference to that .  
I don't know where, if anywhere, this behavior is specified.  It's just
what the Python package installation tools do.  I haven't seen any
other program do this, for better or worse.

- Michael

-- 
Michael Ekstrand — http://elehack.net/

$HOME/.local/bin in $PATH

[Matthias Clasen]

On Mon, 2013-10-28 at 16:27 -0500, Michael Ekstrand wrote:

>  
>  I don't know where, if anywhere, this behavior is specified.  It's just
>  what the Python package installation tools do.  I haven't seen any
>  other program do this, for better or worse.
>   
jhbuild [1] installs itself in $HOME/.local/bin too.

[1] https://developer.gnome.org/jhbuild/stable/getting-started.html.en)

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 28.10.2013 22:48, schrieb Matthias Clasen:
>  On Mon, 2013-10-28 at 16:27 -0500, Michael Ekstrand wrote:
>  
> > I don't know where, if anywhere, this behavior is specified.  It's just
> > what the Python package installation tools do.  I haven't seen any
> > other program do this, for better or worse.
> >
>  
>  jhbuild [1] installs itself in $HOME/.local/bin too.
>  
>  [1] https://developer.gnome.org/jhbuild/stable/getting-started.html.en) 
which does not make wrong and *dangerous* behavior correct

a *hidden* *user writeable* directory *in front* of PATH is
plain stupid security wise and there is not but and not if

$HOME/.local/bin in $PATH

[Matthias Clasen]

On Mon, 2013-10-28 at 22:50 +0100, Reindl Harald wrote:
>  
>  Am 28.10.2013 22:48, schrieb Matthias Clasen:
>  > On Mon, 2013-10-28 at 16:27 -0500, Michael Ekstrand wrote:
>  > 
>  >> I don't know where, if anywhere, this behavior is specified.  It's just
>  >> what the Python package installation tools do.  I haven't seen any
>  >> other program do this, for better or worse.
>  >>
>  > 
>  > jhbuild [1] installs itself in $HOME/.local/bin too.
>  > 
>  > [1] https://developer.gnome.org/jhbuild/stable/getting-started.html.en)
>  
>  which does not make wrong and *dangerous* behavior correct 
Calm down, I didn't claim that it does.
I was specifically replying to: 'I haven't seen any other program do
this'.

$HOME/.local/bin in $PATH

[Christopher]

On Mon, Oct 28, 2013 at 5:50 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  Am 28.10.2013 22:48, schrieb Matthias Clasen:
> > On Mon, 2013-10-28 at 16:27 -0500, Michael Ekstrand wrote:
> >
> >> I don't know where, if anywhere, this behavior is specified.  It's just
> >> what the Python package installation tools do.  I haven't seen any
> >> other program do this, for better or worse.
> >>
> >
> > jhbuild [1] installs itself in $HOME/.local/bin too.
> >
> > [1] https://developer.gnome.org/jhbuild/stable/getting-started.html.en)
>
>  which does not make wrong and *dangerous* behavior correct
>
>  a *hidden* *user writeable* directory *in front* of PATH is
>  plain stupid security wise and there is not but and not if 
+1

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

$HOME/.local/bin in $PATH

[Chris Adams]

Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
>  a *hidden* *user writeable* directory *in front* of PATH is
>  plain stupid security wise and there is not but and not if 
Not really.  Anything that can write to that directory can also write to
shell init scripts, desktop environment autostart settings, etc., all of
which are also dot-files/dot-directories.
-- 
Chris Adams <linux(a)cmadams.net&gt;

$HOME/.local/bin in $PATH

[drago01]

On Tue, Oct 29, 2013 at 2:06 PM, Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
> > a *hidden* *user writeable* directory *in front* of PATH is
> > plain stupid security wise and there is not but and not if
>
>  Not really.  Anything that can write to that directory can also write to
>  shell init scripts, desktop environment autostart settings, etc., all of
>  which are also dot-files/dot-directories. 
Yeah if someone can write to your home directory you are pretty much doomed.

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 30.10.2013 01:11, schrieb drago01:
>  On Tue, Oct 29, 2013 at 2:06 PM, Chris Adams
> <linux(a)cmadams.net&gt; wrote:
> > Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
> >> a *hidden* *user writeable* directory *in front* of PATH is
> >> plain stupid security wise and there is not but and not if
> >
> > Not really.  Anything that can write to that directory can also write to
> > shell init scripts, desktop environment autostart settings, etc., all of
> > which are also dot-files/dot-directories.
>  
>  Yeah if someone can write to your home directory you are pretty much doomed 
yes, but don't you think there is a difference between place
specific code somewhere or give the possibility to override
standard commands?

that's against the main reason why . is *not* in $PATH while
on a windows console every random binary in the currecnt
directory overrides commands

[root@srv-rhsoft:~]$ mkdir test
i could rm -rf ~/ here

[root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
#!/bin/bash
echo "i could rm -rf ~/ here"
__________________________________________________________________

and so that *must not* be easy possible in a *default setup*

$HOME/.local/bin in $PATH

[Chris Adams]

Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
>  [root@srv-rhsoft:~]$ mkdir test
>  i could rm -rf ~/ here
>  
>  [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
>  #!/bin/bash
>  echo "i could rm -rf ~/ here" 
If I can write to files you own, it doesn't matter if there's a
directory in the PATH or not.  I can write this to your .bash_profile:

   /bin/mkdir $HOME/.bin 2> /dev/null
   echo 'echo "i could rm -rf ~/ here"' > $HOME/.bin/mkdir
   chmod +x $HOME/.bin/mkdir
   PATH=$HOME/.bin:$PATH

Sure, it might not take effect immediately, but that's probably not the
point (I can't depend on you running "mkdir" in a shell at any
particular point in time anyway).  You wouldn't gain anything
security-wise by excluding a user-writable directory in PATH.

In fact, having a "known" ~/.local/bin could allow for a more
restrictive SELinux policy on that directory that doesn't let arbitrary
programs running as the user write there (don't know if that is the case
though).

-- 
Chris Adams <linux(a)cmadams.net&gt;

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 30.10.2013 02:03, schrieb Chris Adams:
>  Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
> > [root@srv-rhsoft:~]$ mkdir test
> > i could rm -rf ~/ here
> >
> > [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
> > #!/bin/bash
> > echo "i could rm -rf ~/ here"
>  
>  If I can write to files you own, it doesn't matter if there's a
>  directory in the PATH or not.  I can write this to your .bash_profile:
>  
>     /bin/mkdir $HOME/.bin 2> /dev/null
>     echo 'echo "i could rm -rf ~/ here"' > $HOME/.bin/mkdir
>     chmod +x $HOME/.bin/mkdir
>     PATH=$HOME/.bin:$PATH 
you can do this and that - but that's no valid argumentation
doing bad things in default setups and *at least* do not
place *hidden* diretories there, ther is a good reason why
software like rkhunter alerts if you have hidden directories
somewhere in /usr/bin/

there are three type of users

* people who care about security and know that there are
  enough rough edges but smart enough to take this *not
  as excuse* to create new ones
* the ones which care only a little bit as long it comes
  not to personal comfort decisions and take bad behavior
  as excuse for create more bad behavior
* the ones who don't care about security

when it comes to decisions for a *distribution* only the
first group is relevant, the others are dangerous and
i am not sure who is more dangerous - not care at all
or realize that what happens is wrong and support it

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-10-30 10:23, Reindl Harald wrote:
>  Am 30.10.2013 02:03, schrieb Chris Adams:
> > Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
> >> [root@srv-rhsoft:~]$ mkdir test
> >> i could rm -rf ~/ here
> >>
> >> [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
> >> #!/bin/bash
> >> echo "i could rm -rf ~/ here"
> > If I can write to files you own, it doesn't matter if there's a
> > directory in the PATH or not.  I can write this to your .bash_profile:
> >
> >     /bin/mkdir $HOME/.bin 2> /dev/null
> >     echo 'echo "i could rm -rf ~/ here"' > $HOME/.bin/mkdir
> >     chmod +x $HOME/.bin/mkdir
> >     PATH=$HOME/.bin:$PATH
>  you can do this and that - but that's no valid argumentation
>  doing bad things in default setups and *at least* do not
>  place *hidden* diretories there, ther is a good reason why
>  software like rkhunter alerts if you have hidden directories
>  somewhere in /usr/bin/
>  
Some kind of reference for the bad in having a well-known, hidden 
directory in the path?

As for rkhunter, doesn't it  warn for hidden directories in many places, 
not just /usr/bin? The primary purpose seems to be to discover new, 
hidden directories created by a rootkit or so. I can't see this applies 
here.

--a

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 30.10.2013 10:53, schrieb Alec Leamas:
>  On 2013-10-30 10:23, Reindl Harald wrote:
> > Am 30.10.2013 02:03, schrieb Chris Adams:
> >> Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
> >>> [root@srv-rhsoft:~]$ mkdir test
> >>> i could rm -rf ~/ here
> >>>
> >>> [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
> >>> #!/bin/bash
> >>> echo "i could rm -rf ~/ here"
> >> If I can write to files you own, it doesn't matter if there's a
> >> directory in the PATH or not.  I can write this to your .bash_profile:
> >>
> >>     /bin/mkdir $HOME/.bin 2> /dev/null
> >>     echo 'echo "i could rm -rf ~/ here"' > $HOME/.bin/mkdir
> >>     chmod +x $HOME/.bin/mkdir
> >>     PATH=$HOME/.bin:$PATH
> > you can do this and that - but that's no valid argumentation
> > doing bad things in default setups and *at least* do not
> > place *hidden* diretories there, ther is a good reason why
> > software like rkhunter alerts if you have hidden directories
> > somewhere in /usr/bin/
> >
>  Some kind of reference for the bad in having a well-known, hidden directory in the path?
the *writeable for the user* is the problem

however, since i am one of them with explicit configurations and
setting explicit $PATH in .bashrc and .bash_profile which are
readonly do what you want with defaults, i would appreciate sane
defaults but i can live with doing this job at my own

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-10-30 10:58, Reindl Harald wrote:
>  Am 30.10.2013 10:53, schrieb Alec Leamas:
> > On 2013-10-30 10:23, Reindl Harald wrote:
> >> Am 30.10.2013 02:03, schrieb Chris Adams:
> >>> Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
> >>>> [root@srv-rhsoft:~]$ mkdir test
> >>>> i could rm -rf ~/ here
> >>>>
> >>>> [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
> >>>> #!/bin/bash
> >>>> echo "i could rm -rf ~/ here"
> >>> If I can write to files you own, it doesn't matter if there's a
> >>> directory in the PATH or not.  I can write this to your .bash_profile:
> >>>
> >>>      /bin/mkdir $HOME/.bin 2> /dev/null
> >>>      echo 'echo "i could rm -rf ~/ here"' >
> $HOME/.bin/mkdir
> >>>      chmod +x $HOME/.bin/mkdir
> >>>      PATH=$HOME/.bin:$PATH
> >> you can do this and that - but that's no valid argumentation
> >> doing bad things in default setups and *at least* do not
> >> place *hidden* diretories there, ther is a good reason why
> >> software like rkhunter alerts if you have hidden directories
> >> somewhere in /usr/bin/
> >>
> > Some kind of reference for the bad in having a well-known, hidden directory in the
> path?
>  the *writeable for the user* is the problem 
Any reference for this problem?


--alec

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 30.10.2013 11:20, schrieb Alec Leamas:
>  On 2013-10-30 10:58, Reindl Harald wrote:
> > Am 30.10.2013 10:53, schrieb Alec Leamas:
> >> On 2013-10-30 10:23, Reindl Harald wrote:
> >>> Am 30.10.2013 02:03, schrieb Chris Adams:
> >>>> Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
> >>>>> [root@srv-rhsoft:~]$ mkdir test
> >>>>> i could rm -rf ~/ here
> >>>>>
> >>>>> [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
> >>>>> #!/bin/bash
> >>>>> echo "i could rm -rf ~/ here"
> >>>> If I can write to files you own, it doesn't matter if there's a
> >>>> directory in the PATH or not.  I can write this to your .bash_profile:
> >>>>
> >>>>      /bin/mkdir $HOME/.bin 2> /dev/null
> >>>>      echo 'echo "i could rm -rf ~/ here"' >
> $HOME/.bin/mkdir
> >>>>      chmod +x $HOME/.bin/mkdir
> >>>>      PATH=$HOME/.bin:$PATH
> >>> you can do this and that - but that's no valid argumentation
> >>> doing bad things in default setups and *at least* do not
> >>> place *hidden* diretories there, ther is a good reason why
> >>> software like rkhunter alerts if you have hidden directories
> >>> somewhere in /usr/bin/
> >>>
> >> Some kind of reference for the bad in having a well-known, hidden directory in
> the path?
> > the *writeable for the user* is the problem
>  Any reference for this problem? 
what about consider the implications?
do you really need a written reference for any security relevant fact?
i can write one for you if you prefer links :-)

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-10-30 11:23, Reindl Harald wrote:
>  Am 30.10.2013 11:20, schrieb Alec Leamas:
> > On 2013-10-30 10:58, Reindl Harald wrote:
> >> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>> On 2013-10-30 10:23, Reindl Harald wrote:
> >>>> Am 30.10.2013 02:03, schrieb Chris Adams:
> >>>>> Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
> >>>>>> [root@srv-rhsoft:~]$ mkdir test
> >>>>>> i could rm -rf ~/ here
> >>>>>>
> >>>>>> [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
> >>>>>> #!/bin/bash
> >>>>>> echo "i could rm -rf ~/ here"
> >>>>> If I can write to files you own, it doesn't matter if there's
> a
> >>>>> directory in the PATH or not.  I can write this to your
> .bash_profile:
> >>>>>
> >>>>>       /bin/mkdir $HOME/.bin 2> /dev/null
> >>>>>       echo 'echo "i could rm -rf ~/ here"' >
> $HOME/.bin/mkdir
> >>>>>       chmod +x $HOME/.bin/mkdir
> >>>>>       PATH=$HOME/.bin:$PATH
> >>>> you can do this and that - but that's no valid argumentation
> >>>> doing bad things in default setups and *at least* do not
> >>>> place *hidden* diretories there, ther is a good reason why
> >>>> software like rkhunter alerts if you have hidden directories
> >>>> somewhere in /usr/bin/
> >>>>
> >>> Some kind of reference for the bad in having a well-known, hidden directory
> in the path?
> >> the *writeable for the user* is the problem
> > Any reference for this problem?
>  what about consider the implications?
>  do you really need a written reference for any security relevant fact?
>  i can write one for you if you prefer links :-)
>  
Well, the question is really if someone else out there share your 
concerns about this.

--alec

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 30.10.2013 11:27, schrieb Alec Leamas:
>  On 2013-10-30 11:23, Reindl Harald wrote:
> > Am 30.10.2013 11:20, schrieb Alec Leamas:
> >> On 2013-10-30 10:58, Reindl Harald wrote:
> >>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>> On 2013-10-30 10:23, Reindl Harald wrote:
> >>>>> Am 30.10.2013 02:03, schrieb Chris Adams:
> >>>>>> Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt;
> said:
> >>>>>>> [root@srv-rhsoft:~]$ mkdir test
> >>>>>>> i could rm -rf ~/ here
> >>>>>>>
> >>>>>>> [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
> >>>>>>> #!/bin/bash
> >>>>>>> echo "i could rm -rf ~/ here"
> >>>>>> If I can write to files you own, it doesn't matter if
> there's a
> >>>>>> directory in the PATH or not.  I can write this to your
> .bash_profile:
> >>>>>>
> >>>>>>       /bin/mkdir $HOME/.bin 2> /dev/null
> >>>>>>       echo 'echo "i could rm -rf ~/ here"' >
> $HOME/.bin/mkdir
> >>>>>>       chmod +x $HOME/.bin/mkdir
> >>>>>>       PATH=$HOME/.bin:$PATH
> >>>>> you can do this and that - but that's no valid argumentation
> >>>>> doing bad things in default setups and *at least* do not
> >>>>> place *hidden* diretories there, ther is a good reason why
> >>>>> software like rkhunter alerts if you have hidden directories
> >>>>> somewhere in /usr/bin/
> >>>>>
> >>>> Some kind of reference for the bad in having a well-known, hidden
> directory in the path?
> >>> the *writeable for the user* is the problem
> >> Any reference for this problem?
> > what about consider the implications?
> > do you really need a written reference for any security relevant fact?
> > i can write one for you if you prefer links :-)
> >
>  Well, the question is really if someone else out there share your concerns about this
anybody with interests in security

https://www.google.at/search?q=ssh+chroot+why+needs+the+home+directory+to...

http://binblog.info/2008/04/06/openssh-chrooted-sftp-eg-for-webhosting/
However, the chroot destination must not be owned by the user for security reasons

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-10-30 11:46, Reindl Harald wrote:
>  Am 30.10.2013 11:27, schrieb Alec Leamas:
> > On 2013-10-30 11:23, Reindl Harald wrote:
> >> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>> On 2013-10-30 10:23, Reindl Harald wrote:
> >>>>>> Am 30.10.2013 02:03, schrieb Chris Adams:
> >>>>>>> Once upon a time, Reindl Harald
> <h.reindl(a)thelounge.net&gt; said:
> >>>>>>>> [root@srv-rhsoft:~]$ mkdir test
> >>>>>>>> i could rm -rf ~/ here
> >>>>>>>>
> >>>>>>>> [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
> >>>>>>>> #!/bin/bash
> >>>>>>>> echo "i could rm -rf ~/ here"
> >>>>>>> If I can write to files you own, it doesn't matter if
> there's a
> >>>>>>> directory in the PATH or not.  I can write this to your
> .bash_profile:
> >>>>>>>
> >>>>>>>        /bin/mkdir $HOME/.bin 2> /dev/null
> >>>>>>>        echo 'echo "i could rm -rf ~/ here"'
> > $HOME/.bin/mkdir
> >>>>>>>        chmod +x $HOME/.bin/mkdir
> >>>>>>>        PATH=$HOME/.bin:$PATH
> >>>>>> you can do this and that - but that's no valid argumentation
> >>>>>> doing bad things in default setups and *at least* do not
> >>>>>> place *hidden* diretories there, ther is a good reason why
> >>>>>> software like rkhunter alerts if you have hidden directories
> >>>>>> somewhere in /usr/bin/
> >>>>>>
> >>>>> Some kind of reference for the bad in having a well-known, hidden
> directory in the path?
> >>>> the *writeable for the user* is the problem
> >>> Any reference for this problem?
> >> what about consider the implications?
> >> do you really need a written reference for any security relevant fact?
> >> i can write one for you if you prefer links :-)
> >>
> > Well, the question is really if someone else out there share your concerns about
> this
>  anybody with interests in security
>
>
> https://www.google.at/search?q=ssh+chroot+why+needs+the+home+directory+to...
>
>  http://binblog.info/2008/04/06/openssh-chrooted-sftp-eg-for-webhosting/
>  However, the chroot destination must not be owned by the user for security reasons
>  
So you are arguing that $HOME should be owned by root?!  An interesting 
subject, but isn't it a little off-topic, deserving a separate thread?


--a

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 30.10.2013 11:55, schrieb Alec Leamas:
>  On 2013-10-30 11:46, Reindl Harald wrote:
> > Am 30.10.2013 11:27, schrieb Alec Leamas:
> >> On 2013-10-30 11:23, Reindl Harald wrote:
> >>> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>>> On 2013-10-30 10:23, Reindl Harald wrote:
> >>>>>>> Am 30.10.2013 02:03, schrieb Chris Adams:
> >>>>>>>> Once upon a time, Reindl Harald
> <h.reindl(a)thelounge.net&gt; said:
> >>>>>>>>> [root@srv-rhsoft:~]$ mkdir test
> >>>>>>>>> i could rm -rf ~/ here
> >>>>>>>>>
> >>>>>>>>> [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
> >>>>>>>>> #!/bin/bash
> >>>>>>>>> echo "i could rm -rf ~/ here"
> >>>>>>>> If I can write to files you own, it doesn't matter if
> there's a
> >>>>>>>> directory in the PATH or not.  I can write this to your
> .bash_profile:
> >>>>>>>>
> >>>>>>>>        /bin/mkdir $HOME/.bin 2> /dev/null
> >>>>>>>>        echo 'echo "i could rm -rf ~/
> here"' > $HOME/.bin/mkdir
> >>>>>>>>        chmod +x $HOME/.bin/mkdir
> >>>>>>>>        PATH=$HOME/.bin:$PATH
> >>>>>>> you can do this and that - but that's no valid
> argumentation
> >>>>>>> doing bad things in default setups and *at least* do not
> >>>>>>> place *hidden* diretories there, ther is a good reason why
> >>>>>>> software like rkhunter alerts if you have hidden directories
> >>>>>>> somewhere in /usr/bin/
> >>>>>>>
> >>>>>> Some kind of reference for the bad in having a well-known, hidden
> directory in the path?
> >>>>> the *writeable for the user* is the problem
> >>>> Any reference for this problem?
> >>> what about consider the implications?
> >>> do you really need a written reference for any security relevant fact?
> >>> i can write one for you if you prefer links :-)
> >>>
> >> Well, the question is really if someone else out there share your concerns about
> this
> > anybody with interests in security
> >
> >
> https://www.google.at/search?q=ssh+chroot+why+needs+the+home+directory+to...
> >
> > http://binblog.info/2008/04/06/openssh-chrooted-sftp-eg-for-webhosting/
> > However, the chroot destination must not be owned by the user for security reasons
> >
>  So you are arguing that $HOME should be owned by root?!   
*no i do not*

i gave you a starting point to learn about security and the reason
for sftp-chroot doing so is that someone could use race-conditions
to bypass the security

if you do not understand that allowing any random application running
with your normal user permissions place a binary inside PATH is a bad
idea i really can not help you

security is *always* a process and layered, there are a lot of things
to consider in different levels and while you can not gain 100%
security you can make it harder to bypass restrictions on several
places and doing things which are clearly against is not smart

you can decide taht security is not that important for you
but a distribution as such should not make such wrong decisions for all users

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-10-30 12:25, Reindl Harald wrote:
>  Am 30.10.2013 11:55, schrieb Alec Leamas:
> > On 2013-10-30 11:46, Reindl Harald wrote:
> >> Am 30.10.2013 11:27, schrieb Alec Leamas:
> >>> On 2013-10-30 11:23, Reindl Harald wrote:
> >>>> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>>>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>>>> On 2013-10-30 10:23, Reindl Harald wrote:
> >>>>>>>> Am 30.10.2013 02:03, schrieb Chris Adams:
> >>>>>>>>> Once upon a time, Reindl Harald
> <h.reindl(a)thelounge.net&gt; said:
> >>>>>>>>>> [root@srv-rhsoft:~]$ mkdir test
> >>>>>>>>>> i could rm -rf ~/ here
> >>>>>>>>>>
> >>>>>>>>>> [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
> >>>>>>>>>> #!/bin/bash
> >>>>>>>>>> echo "i could rm -rf ~/ here"
> >>>>>>>>> If I can write to files you own, it doesn't
> matter if there's a
> >>>>>>>>> directory in the PATH or not.  I can write this to
> your .bash_profile:
> >>>>>>>>>
> >>>>>>>>>         /bin/mkdir $HOME/.bin 2> /dev/null
> >>>>>>>>>         echo 'echo "i could rm -rf ~/
> here"' > $HOME/.bin/mkdir
> >>>>>>>>>         chmod +x $HOME/.bin/mkdir
> >>>>>>>>>         PATH=$HOME/.bin:$PATH
> >>>>>>>> you can do this and that - but that's no valid
> argumentation
> >>>>>>>> doing bad things in default setups and *at least* do not
> >>>>>>>> place *hidden* diretories there, ther is a good reason
> why
> >>>>>>>> software like rkhunter alerts if you have hidden
> directories
> >>>>>>>> somewhere in /usr/bin/
> >>>>>>>>
> >>>>>>> Some kind of reference for the bad in having a well-known,
> hidden directory in the path?
> >>>>>> the *writeable for the user* is the problem
> >>>>> Any reference for this problem?
> >>>> what about consider the implications?
> >>>> do you really need a written reference for any security relevant fact?
> >>>> i can write one for you if you prefer links :-)
> >>>>
> >>> Well, the question is really if someone else out there share your concerns
> about this
> >> anybody with interests in security
> >>
> >>
> https://www.google.at/search?q=ssh+chroot+why+needs+the+home+directory+to...
> >>
> >> http://binblog.info/2008/04/06/openssh-chrooted-sftp-eg-for-webhosting/
> >> However, the chroot destination must not be owned by the user for security
> reasons
> >>
> > So you are arguing that $HOME should be owned by root?!
>  *no i do not* 
OK
>  i gave you a starting point to learn about security and the reason
>  for sftp-chroot doing so is that someone could use race-conditions
>  to bypass the security
>
>  if you do not understand that allowing any random application running
>  with your normal user permissions place a binary inside PATH is a bad
>  idea i really can not help you
>
>  security is *always* a process and layered, there are a lot of things
>  to consider in different levels and while you can not gain 100%
>  security you can make it harder to bypass restrictions on several
>  places and doing things which are clearly against is not smart
>
>  you can decide taht security is not that important for you
>  but a distribution as such should not make such wrong decisions for all users 
No,
it should not.  However,  the right decision is in many cases a 
trade-off between security and usabilty, not always with a single 
answer. Allowing users to install sw (i. e., allowing random 
applications to put things in $PATH) has of course security 
implications. Dis-allowing has usability aspects.  My personal view is 
that for the distribution  the defaults should  allow  and support 
user-installed sw.

And, isn't  this still a little off-topic? Current defaults already has 
~/bin in $PATH, and user can certainly put things there. Isn't the issue 
here if having a hidden, writeable directory in $PATH is such a bad 
idea, given that users actually can install sw?


--alec

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 30.10.2013 13:00, schrieb Alec Leamas:
>  On 2013-10-30 12:25, Reindl Harald wrote:
> > i gave you a starting point to learn about security and the reason
> > for sftp-chroot doing so is that someone could use race-conditions
> > to bypass the security
> >
> > if you do not understand that allowing any random application running
> > with your normal user permissions place a binary inside PATH is a bad
> > idea i really can not help you
> >
> > security is *always* a process and layered, there are a lot of things
> > to consider in different levels and while you can not gain 100%
> > security you can make it harder to bypass restrictions on several
> > places and doing things which are clearly against is not smart
> >
> > you can decide that security is not that important for you
> > but a distribution as such should not make such wrong decisions for all users
>  No, it should not.  However,  the right decision is in many cases a trade-off between
> security and usabilty, not
>  always with a single answer. Allowing users to install sw (i. e., allowing random
> applications to put things in
>  $PATH) has of course security implications. Dis-allowing has usability aspects.  My
> personal view is that for the
>  distribution the defaults should allow and support user-installed sw. 
the distribution should *not* train users doing this in their userhome

that is why /usr/local exists and software besides packages belongs
there and should be installed as root, 1 out of 1000 users need
to install software in the userhome, if so they should learn
about the implications and have a small barrier

it's not that hard to edit .bash_profile but you need to do it by hand
which means you have to spend a thought about it which is completly
different to "i did not know about the door i never opened by myself"

>  And, isn't  this still a little off-topic?  
no it is not because the topic is in the subject

>  Current defaults already has ~/bin in $PATH, and user can certainly
> put
>  things there. Isn't the issue here if having a hidden, writeable directory 
>  in $PATH is such a bad idea, given that users actually can install sw? 
guess how many users are aware of the hidden directory compared with
"bin" in the userhome and how often someone may take a look

you can now argue that the user does not look in both of them
and i argue that extaly *this* is the problem
the defaults are dangerous for the majority of ordinary users

but there are users sometimes take a look what is in their userhome
the chance doing also in hidden subdirectories is by zero

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-10-30 13:08, Reindl Harald wrote:
>  Am 30.10.2013 13:00, schrieb Alec Leamas:
> > On 2013-10-30 12:25, Reindl Harald wrote:
> >> i gave you a starting point to learn about security and the reason
> >> for sftp-chroot doing so is that someone could use race-conditions
> >> to bypass the security
> >>
> >> if you do not understand that allowing any random application running
> >> with your normal user permissions place a binary inside PATH is a bad
> >> idea i really can not help you
> >>
> >> security is *always* a process and layered, there are a lot of things
> >> to consider in different levels and while you can not gain 100%
> >> security you can make it harder to bypass restrictions on several
> >> places and doing things which are clearly against is not smart
> >>
> >> you can decide that security is not that important for you
> >> but a distribution as such should not make such wrong decisions for all users
> > No, it should not.  However,  the right decision is in many cases a trade-off between
> security and usabilty, not
> > always with a single answer. Allowing users to install sw (i. e., allowing random
> applications to put things in
> > $PATH) has of course security implications. Dis-allowing has usability aspects.  My
> personal view is that for the
> > distribution the defaults should allow and support user-installed sw.
>  the distribution should *not* train users doing this in their userhome
>
>  that is why /usr/local exists and software besides packages belongs
>  there and should be installed as root, 1 out of 1000 users need
>  to install software in the userhome, if so they should learn
>  about the implications and have a small barrier
>
>  it's not that hard to edit .bash_profile but you need to do it by hand
>  which means you have to spend a thought about it which is completly
>  different to "i did not know about the door i never opened by myself
>
> > And, isn't  this still a little off-topic?
>  no it is not because the topic is in the subject
>
> > Current defaults already has ~/bin in $PATH, and user can certainly put
> > things there. Isn't the issue here if having a hidden, writeable directory
> > in $PATH is such a bad idea, given that users actually can install sw?
>  guess how many users are aware of the hidden directory compared with
>  "bin" in the userhome and how often someone may take a look
>
>  you can now argue that the user does not look in both of them
>  and i argue that extaly *this* is the problem
>  the defaults are dangerous for the majority of ordinary users
>
>  but there are users sometimes take a look what is in their userhome
>  the chance doing also in hidden subdirectories is by zero
>  
I'm not convinced by your arguments, and to be fair I havn't really 
argued for my own position. I suggest that we agree on that we disagree:
  - if  user-installed sw in $HOME should be supported.
  - if  having ~/.local/bin in $PATH is a bad enough idea to drop it.

--alec

$HOME/.local/bin in $PATH

[Petr Viktorin]

On 10/30/2013 01:08 PM, Reindl Harald wrote:
>  Am 30.10.2013 13:00, schrieb Alec Leamas:
> > On 2013-10-30 12:25, Reindl Harald wrote:
> >> i gave you a starting point to learn about security and the reason
> >> for sftp-chroot doing so is that someone could use race-conditions
> >> to bypass the security
> >>
> >> if you do not understand that allowing any random application running
> >> with your normal user permissions place a binary inside PATH is a bad
> >> idea i really can not help you
> >>
> >> security is *always* a process and layered, there are a lot of things
> >> to consider in different levels and while you can not gain 100%
> >> security you can make it harder to bypass restrictions on several
> >> places and doing things which are clearly against is not smart
> >>
> >> you can decide that security is not that important for you
> >> but a distribution as such should not make such wrong decisions for all users
> > No, it should not.  However,  the right decision is in many cases a trade-off between
> security and usabilty, not
> > always with a single answer. Allowing users to install sw (i. e., allowing random
> applications to put things in
> > $PATH) has of course security implications. Dis-allowing has usability aspects.  My
> personal view is that for the
> > distribution the defaults should allow and support user-installed sw.
>
>  the distribution should *not* train users doing this in their userhome
>
>  that is why /usr/local exists and software besides packages belongs
>  there and should be installed as root, 1 out of 1000 users need
>  to install software in the userhome, 
Do you have any source for that assumption?
For example university students usually simply can't install as root.

>  if so they should learn
>  about the implications and have a small barrier 
No, they should just install the software and be done with it.

>  it's not that hard to edit .bash_profile but you need to do it by
> hand
>  which means you have to spend a thought about it which is completly
>  different to "i did not know about the door i never opened by myself" 
Why should I do that? I expect `pip install --user` to install my 
package without me having to fiddle with .bash_profile.

> > And, isn't  this still a little off-topic?
>
>  no it is not because the topic is in the subject
>
> > Current defaults already has ~/bin in $PATH, and user can certainly put
> > things there. Isn't the issue here if having a hidden, writeable directory
> > in $PATH is such a bad idea, given that users actually can install sw?
>
>  guess how many users are aware of the hidden directory compared with
>  "bin" in the userhome and how often someone may take a look 
Also guess how many users don't care.
Do you have data to make anything else than a guess?

>  you can now argue that the user does not look in both of them
>  and i argue that extaly *this* is the problem
>  the defaults are dangerous for the majority of ordinary users 
I personally like that ~/bin contains what I put there myself by hand, 
and ~/.local/bin has what was installed via pip.

>  but there are users sometimes take a look what is in their userhome
>  the chance doing also in hidden subdirectories is by zero 
This is wild speculation.
You can just echo $PATH to see what directories are in $PATH.


Also, if you bother securing .bash_profile so that rogue programs can't 
write into it, you can easily check if $PATH is set the way you want it.
If you don't bother, it doesn't matter if malware installs to 
~/.local/bin/rootkit or ~/.rootkit

-- 
Petr³

$HOME/.local/bin in $PATH

[Ralf Corsepius]

On 10/30/2013 01:08 PM, Reindl Harald wrote:
>  Am 30.10.2013 13:00, schrieb Alec Leamas:
> > On 2013-10-30 12:25, Reindl Harald wrote:
> > No, it should not. However, the right decision is in many cases a 
> > trade-off between security and usabilty, not always with a single 
> > answer. Allowing users to install sw (i. e., allowing random 
> > applications to put things in $PATH) has of course security 
> > implications. Dis-allowing has usability aspects. My personal view is 
> > that for the distribution the defaults should allow and support 
> > user-installed sw. 
>  the distribution should *not* train users doing this in their userhome 
Nonsense.
>  that is why /usr/local exists 
/usr/local exist to allow sys-admins to override the system-wide 
installation (/ and /usr).

>    and software besides packages belongs
>  there and should be installed as root, 1 out of 1000 users need
>  to install software in the userhome, if so they should learn
>  about the implications and have a small barrier 
You should not start to generalize
on your limited scope of use-cases.

Surely there are installations where users are not allowed to install 
executables, but this is just local convention and by no means is the norm.

Besides that, what and where users put things underneath of $HOME is not 
a distro's busness.

Ralf

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 30.10.2013 15:29, schrieb Ralf Corsepius:
>  On 10/30/2013 01:08 PM, Reindl Harald wrote:
>  Besides that, what and where users put things underneath of $HOME is not a distro's
> busness 
and so it is not a distro's business to add something to $PATH
inside the userhome and finally you agreed what i said by try
to disagree

$HOME/.local/bin in $PATH

[Ralf Corsepius]

On 10/30/2013 03:36 PM, Reindl Harald wrote:
>  Am 30.10.2013 15:29, schrieb Ralf Corsepius:
> > On 10/30/2013 01:08 PM, Reindl Harald wrote:
> > Besides that, what and where users put things underneath of $HOME is not a
> distro's busness
>  and so it is not a distro's business to add something to $PATH
>  inside the userhome 
Yes, I agree to this. Automatically adding $HOME/.local/bin to
$PATH is 
a bad idea.

>    and finally you agreed what i said by try
>  to disagree 
Well your view of "users must not add binaries" underneath of
$HOME is 
non-sense. Actually it's the only way for ordinary users to install 
per-user installed SW.

Ralf

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-10-30 15:50, Ralf Corsepius wrote:
>  On 10/30/2013 03:36 PM, Reindl Harald wrote:
> >
> > Am 30.10.2013 15:29, schrieb Ralf Corsepius:
> >> On 10/30/2013 01:08 PM, Reindl Harald wrote:
> >> Besides that, what and where users put things underneath of $HOME is 
> >> not a distro's busness
>
>  [cut]
>  
Is it really that simple?
- We respect the ancient traditions of ~/bin and ~/man.
- We respect the XDG specification for ~/.local/share
- This discussion: we respect ~/.local/bin, even if it's unclear if it's 
in the XDG spec.
- As Daniel Walsh pointed out in this thread, the selinux setup respect 
also ~/.local/bin

Bottom line: Fedora is not completely agnostic as to where users have 
their stuff,  there are some assumptions.

OTOH, all these could be defined as coming from some kind of 
"upstream".  Perhaps the proper solution here is to patch the XDG 
specification so that it becomes clear on ~/local/bin (and probably also 
~/.local/lib).  Since Lennart Poettering is one of (the?) main 
contributor(s)  to this spec and also have been advocating the use of 
~/.local/bin it should be feasible.

--alec

$HOME/.local/bin in $PATH

[Scott Schmit]

On Wed, Oct 30, 2013 at 01:08:48PM +0100, Reindl Harald wrote:
>  Am 30.10.2013 13:00, schrieb Alec Leamas:
>  > Current defaults already has ~/bin in $PATH, and user can certainly put
>  > things there. Isn't the issue here if having a hidden, writeable directory 
>  > in $PATH is such a bad idea, given that users actually can install sw?
>  
>  guess how many users are aware of the hidden directory compared with
>  "bin" in the userhome and how often someone may take a look 
The only
reason I know I can put executables in $HOME/bin and have it
just work is *because* it's in my $PATH.  $HOME/bin isn't created for
new accounts.  FWIW, neither is $HOME/.local.

$HOME/.bashrc $HOME/.bash_profile are both already executed on bash
invocation, and they're writable to the user.  If some exploit or
malware can inject entire files into my home directory and mark them
executable, and I'm allowed to execute anything out of $HOME, then it
doesn't matter what's in $PATH or not.

I suspect that SELinux policies already prevent creation of files in
$HOME by confined domains, making this less of an issue anyway.  If you
turn off SELinux and don't want executables in $HOME, then mount /home
noexec.

I imagine $HOME/.local/bin is ahead of the system executables so that if
my sysadmin has an ancient version of some software package and I need
something newer, I can build and install a newer version in my home
directory.  I remember doing this at school when I was using lab
machines.

What's the issue here?

-- 
Scott Schmit

$HOME/.local/bin in $PATH

[Christopher]

On Wed, Oct 30, 2013 at 6:27 AM, Alec Leamas <leamas.alec(a)gmail.com&gt; wrote:
>  On 2013-10-30 11:23, Reindl Harald wrote:
> >
> > Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>
> >> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>
> >>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>
> >>>> On 2013-10-30 10:23, Reindl Harald wrote:
> >>>>>
> >>>>> Am 30.10.2013 02:03, schrieb Chris Adams:
> >>>>>>
> >>>>>> Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt;
> said:
> >>>>>>>
> >>>>>>> [root@srv-rhsoft:~]$ mkdir test
> >>>>>>> i could rm -rf ~/ here
> >>>>>>>
> >>>>>>> [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir
> >>>>>>> #!/bin/bash
> >>>>>>> echo "i could rm -rf ~/ here"
> >>>>>>
> >>>>>> If I can write to files you own, it doesn't matter if
> there's a
> >>>>>> directory in the PATH or not.  I can write this to your
> >>>>>> .bash_profile:
> >>>>>>
> >>>>>>       /bin/mkdir $HOME/.bin 2> /dev/null
> >>>>>>       echo 'echo "i could rm -rf ~/ here"' >
> $HOME/.bin/mkdir
> >>>>>>       chmod +x $HOME/.bin/mkdir
> >>>>>>       PATH=$HOME/.bin:$PATH
> >>>>>
> >>>>> you can do this and that - but that's no valid argumentation
> >>>>> doing bad things in default setups and *at least* do not
> >>>>> place *hidden* diretories there, ther is a good reason why
> >>>>> software like rkhunter alerts if you have hidden directories
> >>>>> somewhere in /usr/bin/
> >>>>>
> >>>> Some kind of reference for the bad in having a well-known, hidden
> >>>> directory in the path?
> >>>
> >>> the *writeable for the user* is the problem
> >>
> >> Any reference for this problem?
> >
> > what about consider the implications?
> > do you really need a written reference for any security relevant fact?
> > i can write one for you if you prefer links :-)
> >
>  Well, the question is really if someone else out there share your concerns
>  about this. 
I share them, and I agree that it is the argument, not a citation,
that demonstrates the merits of the security case.

Supporting user-installed software in $HOME is a fine goal... but it
shouldn't be done in a way that puts user-installed software earlier
in the path by default, or expanding the number of points for users to
watch for bad-behaving apps. As a long-time user of Fedora, I'd have
never even thought of checking for executables in ~/.local/bin, until
I happened to read this thread... and when I did, it was quite
unnerving.

The one reprieve from all this, is that, when I checked, it was later
in the path than the system paths (at least for me), not earlier, as
was previously asserted in this thread.

Of course, one can always check the contents of $PATH directly... but
there's some level of trust here... because that can get quite long,
and lazy users like me assume (perhaps badly) that if we didn't modify
it in our login scripts, it wasn't modified to include any additional
user-writable paths beyond ~/bin

And, the xdg argument doesn't seem like a sufficient argument for
me... we're talking about login scripts, not X. It is very unintuitive
that an xdg-related directory would be on the default path for a bash
login, if you're not even running X. This is a bash profile... not an
X profile...

The biggest problem isn't that it's hidden or that it's there by
default, or that it's writable by potentially bad-behaving software.
The biggest problem is simply that users don't know about it. I
certainly didn't.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-10-30 15:05, Christopher wrote:
>  On Wed, Oct 30, 2013 at 6:27 AM, Alec Leamas
> <leamas.alec(a)gmail.com&gt; wrote:
> > On 2013-10-30 11:23, Reindl Harald wrote:
> >> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>> Some kind of reference for the bad in having a well-known, hidden
> >>>>> directory in the path?
> >>>> the *writeable for the user* is the problem
> >>> Any reference for this problem?
> >> what about consider the implications?
> >> do you really need a written reference for any security relevant fact?
> >> i can write one for you if you prefer links :-)
> >>
> > Well, the question is really if someone else out there share your concerns
> > about this.
>  I share them, and I agree that it is the argument, not a citation,
>  that demonstrates the merits of the security case.
>
>  Supporting user-installed software in $HOME is a fine goal... but it
>  shouldn't be done in a way that puts user-installed software earlier
>  in the path by default, or expanding the number of points for users to
>  watch for bad-behaving apps. As a long-time user of Fedora, I'd have
>  never even thought of checking for executables in ~/.local/bin, until
>  I happened to read this thread... and when I did, it was quite
>  unnerving.
>
>  The one reprieve from all this, is that, when I checked, it was later
>  in the path than the system paths (at least for me), not earlier, as
>  was previously asserted in this thread. 
Yup, same for me, it's after the system
paths. Which is fine, 
user-installed sw should not override system's by default.
>  [cut]
>
>  And, the xdg argument doesn't seem like a sufficient argument for
>  me... we're talking about login scripts, not X. It is very unintuitive
>  that an xdg-related directory would be on the default path for a bash
>  login, if you're not even running X. This is a bash profile... not an
>  X profile... 
Still, actual usecases such as pip install are not limited to GUI 
programs. IMHO, the need for user installs together with the already 
established ~/.local/share makes it natural to use ~/.local as an 
installation prefix. Which implies  ~/.local/bin and also ~/.local/lib 
in the long run. Why should this just apply to GUI programs?
>  The biggest problem isn't that it's hidden or that it's
> there by
>  default, or that it's writable by potentially bad-behaving software.
>  The biggest problem is simply that users don't know about it. I
>  certainly didn't. 
Agreed, this is the problem. However, to me it  seems better
to use a 
consistent solution based on ~/.local rather than having each 
user-installed non-rpm package create it's own idea of a bin directory,  
possibly fiddling witg $PATH to make it work. Yes, it takes some time to 
learn - but isn't it actually easier in the long run?

--alec

$HOME/.local/bin in $PATH

[Ben Boeckel]

On Wed, 30 Oct, 2013 at 14:05:05 GMT, Christopher wrote:
>  And, the xdg argument doesn't seem like a sufficient argument
> for
>  me... we're talking about login scripts, not X. It is very unintuitive
>  that an xdg-related directory would be on the default path for a bash
>  login, if you're not even running X. This is a bash profile... not an
>  X profile... 
The XDG spec parts aren't really X-specific anyways. Does having to set
W3M_DOWNLOAD_DIR as well as XDG_DOWNLOAD_DIR sound at all appealing? I
see that XDG comes from "X Desktop Group", but for XDG_* stuff.
Backronyming to "[Cross] Desktop Guidelines" (of which a TTY login is
just a degenerative case for most things (icons, menus, etc.)) wouldn't
be the worst thing...

-- Ben

$HOME/.local/bin in $PATH

[Nicolas Mailhot]

Hi,

Anyway what makes xdg specs a total wreakage is the way they've replaced
dotfiles with other dotfiles only to create prettyfied localized symlinks
à la windows (a bad case of over-engineering and aping another os without
understanding drawbacks)

Had they specified a ~/xdg/ root, with a static directory hierarchy under
it, no hidden files, no you-need-to-run-a-command-to-known-where-stuff is,
no magic env variables, it would have been a sane environment for apps,
scripts, selinux, apparmor, etc

And they could even have auto-replaced the standard static names with
localized labels in GUI file browsers with no functionality loss at all.

As it is we got a frankeinspec, a little better than what existed before,
and completely hostile to anyone trying to actually use it to deploy
user-specific bits


Regards,

-- 
Nicolas Mailhot

$HOME/.local/bin in $PATH

[drago01]

On Thu, Oct 31, 2013 at 10:01 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  Hi,
>
>  Anyway what makes xdg specs a total wreakage is the way they've replaced
>  dotfiles with other dotfiles only to create prettyfied localized symlinks 
That's incorrect. The "prettyfied localized symlinks" are neither
symlinks nor are they hidden.

>  à la windows (a bad case of over-engineering and aping another os
> without
>  understanding drawbacks) 
Seems like you do not really understand what you are criticizing.

>  Had they specified a ~/xdg/ root, with a static directory hierarchy
> under
>  it, no hidden files, no you-need-to-run-a-command-to-known-where-stuff is,
>  no magic env variables, it would have been a sane environment for apps,
>  scripts, selinux, apparmor, etc 
The hidden directories replaced the mess that we had before where each
app stores stuff
in random (hidden) directories. Having a standardized directory
structure is actually
a "sane environment". As for why they are hidden (and always have
been) is because you
do not want to bother the user with them most of the time.

$HOME/.local/bin in $PATH

[Mathieu Bridon]

On Thu, 2013-10-31 at 10:12 +0100, drago01 wrote:
>  As for why they are hidden (and always have been) is because you
>  do not want to bother the user with them most of the time. 
That being said, they could have not started by a ".", but still be
hidden by the GUI file managers like Nautilus (for example by listing
them in a .hidden file).

That could have pleased those who don't like hidden files, while at the
same time not bothering users who don't want to see them.

In any case, it's not worth changing everything now.

I for one am happy that things are more and more moving to the .config
and .local folders. :)


-- 
Mathieu

$HOME/.local/bin in $PATH

[Andrew Haley]

On 10/30/2013 10:27 AM, Alec Leamas wrote:
>  On 2013-10-30 11:23, Reindl Harald wrote:
> > Am 30.10.2013 11:20, schrieb Alec Leamas:
> >> On 2013-10-30 10:58, Reindl Harald wrote:
> >>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>> Some kind of reference for the bad in having a well-known, hidden
> directory in the path?
> >>> the *writeable for the user* is the problem
> >> Any reference for this problem?
> > what about consider the implications?
> > do you really need a written reference for any security relevant fact?
> > i can write one for you if you prefer links :-)
> >
>  Well, the question is really if someone else out there share your 
>  concerns about this. 
Why does it matter?  A hidden directory in everyone's path is obviously
useful to an attacker, and (IMO) more useful to an attacker than to a user.
You shouldn't need any references.

Andrew.

$HOME/.local/bin in $PATH

[drago01]

On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley <aph(a)redhat.com&gt; wrote:
>  On 10/30/2013 10:27 AM, Alec Leamas wrote:
> > On 2013-10-30 11:23, Reindl Harald wrote:
> >> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>> Some kind of reference for the bad in having a well-known, hidden
> directory in the path?
> >>>> the *writeable for the user* is the problem
> >>> Any reference for this problem?
> >> what about consider the implications?
> >> do you really need a written reference for any security relevant fact?
> >> i can write one for you if you prefer links :-)
> >>
> > Well, the question is really if someone else out there share your
> > concerns about this.
>
>  Why does it matter?  A hidden directory in everyone's path is obviously
>  useful to an attacker, and (IMO) more useful to an attacker than to a user. 
The attacker needs to be able to write to your home directory to take
advantage of it.
And if he can do that (you lost) he has numerous other ways of doing it.

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 01.11.2013 10:38, schrieb drago01:
>  On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley <aph(a)redhat.com&gt;
> wrote:
> > On 10/30/2013 10:27 AM, Alec Leamas wrote:
> >> On 2013-10-30 11:23, Reindl Harald wrote:
> >>> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>>> Some kind of reference for the bad in having a well-known, hidden
> directory in the path?
> >>>>> the *writeable for the user* is the problem
> >>>> Any reference for this problem?
> >>> what about consider the implications?
> >>> do you really need a written reference for any security relevant fact?
> >>> i can write one for you if you prefer links :-)
> >>>
> >> Well, the question is really if someone else out there share your
> >> concerns about this.
> >
> > Why does it matter?  A hidden directory in everyone's path is obviously
> > useful to an attacker, and (IMO) more useful to an attacker than to a user.
>  
>  The attacker needs to be able to write to your home directory to take
>  advantage of it.
>  And if he can do that (you lost) he has numerous other ways of doing it 
so the people decided not put the current directory in the
PATH on Unix *for security reasons* decades ago must be
fools and if you would have been born as this happened you
would have told them "forget it, in that case you are lost"

heroic attitude :-)

*yes* you have lost and in doubt in this situation the
interesting thing is how large the impact becomes

$HOME/.local/bin in $PATH

[Thomas Moschny]

2013/11/1 Reindl Harald <h.reindl(a)thelounge.net&gt;:
> > The attacker needs to be able to write to your home directory to
> take
> > advantage of it.
> > And if he can do that (you lost) he has numerous other ways of doing it
>
>  so the people decided not put the current directory in the
>  PATH on Unix *for security reasons* decades ago must be
>  fools 
Not having cwd in the path is a protection against malicious (or at
least joking) users on the same system: Otherwise they could easily
fool you to execute e.g. a file named 'ls' in their home doing
something evil.

- Thomas

$HOME/.local/bin in $PATH

[Petr Viktorin]

On 11/01/2013 10:48 AM, Reindl Harald wrote:
>  Am 01.11.2013 10:38, schrieb drago01:
> > On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley <aph(a)redhat.com&gt; wrote:
> >> On 10/30/2013 10:27 AM, Alec Leamas wrote:
> >>> On 2013-10-30 11:23, Reindl Harald wrote:
> >>>> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>>>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>>>> Some kind of reference for the bad in having a well-known,
> hidden directory in the path?
> >>>>>> the *writeable for the user* is the problem
> >>>>> Any reference for this problem?
> >>>> what about consider the implications?
> >>>> do you really need a written reference for any security relevant fact?
> >>>> i can write one for you if you prefer links :-)
> >>>>
> >>> Well, the question is really if someone else out there share your
> >>> concerns about this.
> >>
> >> Why does it matter?  A hidden directory in everyone's path is obviously
> >> useful to an attacker, and (IMO) more useful to an attacker than to a user.
> >
> > The attacker needs to be able to write to your home directory to take
> > advantage of it.
> > And if he can do that (you lost) he has numerous other ways of doing it
>
>  so the people decided not put the current directory in the
>  PATH on Unix *for security reasons* decades ago must be
>  fools and if you would have been born as this happened you
>  would have told them "forget it, in that case you are lost" 
Was that even for security reasons?
Anyway, how this is relevant to this discussion? How does a static, 
well-known (maybe not to you so far) bin directory compare to the danger 
of . PATH and, say, a rootkit in /tmp/cp?

>  heroic attitude :-)
>
>  *yes* you have lost and in doubt in this situation the
>  interesting thing is how large the impact becomes 
Users of a multi-user system get to customize their system without 
having to bother a sysadmin, and without seeing technical details of 
that's accompished mixed with their ~/Photos and ~/Documents.

What impact did *you* have in mind?

-- 
Petr³

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 01.11.2013 11:08, schrieb Petr Viktorin:
>  On 11/01/2013 10:48 AM, Reindl Harald wrote:
> > Am 01.11.2013 10:38, schrieb drago01:
> >> On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley <aph(a)redhat.com&gt; wrote:
> >>> On 10/30/2013 10:27 AM, Alec Leamas wrote:
> >>>> On 2013-10-30 11:23, Reindl Harald wrote:
> >>>>> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>>>>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>>>>> Some kind of reference for the bad in having a
> well-known, hidden directory in the path?
> >>>>>>> the *writeable for the user* is the problem
> >>>>>> Any reference for this problem?
> >>>>> what about consider the implications?
> >>>>> do you really need a written reference for any security relevant
> fact?
> >>>>> i can write one for you if you prefer links :-)
> >>>>>
> >>>> Well, the question is really if someone else out there share your
> >>>> concerns about this.
> >>>
> >>> Why does it matter?  A hidden directory in everyone's path is obviously
> >>> useful to an attacker, and (IMO) more useful to an attacker than to a user.
> >>
> >> The attacker needs to be able to write to your home directory to take
> >> advantage of it.
> >> And if he can do that (you lost) he has numerous other ways of doing it
> >
> > so the people decided not put the current directory in the
> > PATH on Unix *for security reasons* decades ago must be
> > fools and if you would have been born as this happened you
> > would have told them "forget it, in that case you are lost"
>  
>  Was that even for security reasons? 
yes, Google may help here

>  Anyway, how this is relevant to this discussion? How does a static,
> well-known (maybe not to you so far) bin
>  directory compare to the danger of . PATH and, say, a rootkit in /tmp/cp? 
the rootkit in /tmp/cp is in your path?

> > heroic attitude :-)
> >
> > *yes* you have lost and in doubt in this situation the
> > interesting thing is how large the impact becomes
>  
>  Users of a multi-user system get to customize their system without having to bother a
> sysadmin, and without seeing
>  technical details of that's accompished mixed with their ~/Photos and ~/Documents.
on multi-user systems it is *intentional* that the user does *not* install
software at it's own and if this should be the case the admin *one time*
will add a directory to PATH and say "there you go"

>  What impact did *you* have in mind? 
the *security* impact after "you have lost" happened

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-11-01 11:14, Reindl Harald wrote:
>  [cut ]
>  on multi-user systems it is *intentional* that the user does *not* install
>  software at it's own and if this should be the case the admin *one time*
>  will add a directory to PATH and say "there you go"
>  [cut]
>  
Not necessarily  (or even most often) true,  as obvious from this 
thread. Perhaps at your site(s), but not the general case.

$HOME/.local/bin in $PATH

[Petr Viktorin]

On 11/01/2013 11:14 AM, Reindl Harald wrote:
>  Am 01.11.2013 11:08, schrieb Petr Viktorin:
> > On 11/01/2013 10:48 AM, Reindl Harald wrote:
> >> Am 01.11.2013 10:38, schrieb drago01:
> >>> On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley <aph(a)redhat.com&gt; wrote:
> >>>> On 10/30/2013 10:27 AM, Alec Leamas wrote:
> >>>>> On 2013-10-30 11:23, Reindl Harald wrote:
> >>>>>> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>>>>>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>>>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>>>>>> Some kind of reference for the bad in having a
> well-known, hidden directory in the path?
> >>>>>>>> the *writeable for the user* is the problem
> >>>>>>> Any reference for this problem?
> >>>>>> what about consider the implications?
> >>>>>> do you really need a written reference for any security relevant
> fact?
> >>>>>> i can write one for you if you prefer links :-)
> >>>>>>
> >>>>> Well, the question is really if someone else out there share your
> >>>>> concerns about this.
> >>>>
> >>>> Why does it matter?  A hidden directory in everyone's path is
> obviously
> >>>> useful to an attacker, and (IMO) more useful to an attacker than to a
> user.
> >>>
> >>> The attacker needs to be able to write to your home directory to take
> >>> advantage of it.
> >>> And if he can do that (you lost) he has numerous other ways of doing it
> >>
> >> so the people decided not put the current directory in the
> >> PATH on Unix *for security reasons* decades ago must be
> >> fools and if you would have been born as this happened you
> >> would have told them "forget it, in that case you are lost"
> >
> > Was that even for security reasons?
>
>  yes, Google may help here
>
> > Anyway, how this is relevant to this discussion? How does a static, well-known (maybe
> not to you so far) bin
> > directory compare to the danger of . PATH and, say, a rootkit in /tmp/cp?
>
>  the rootkit in /tmp/cp is in your path? 
If . would have been in $PATH and I happened to be in /tmp, then yes.
On the other hand if I install something in my home, it does not affect 
other users in any way.

(As an aside: the old Unix security decisions assumed the user trusts 
his or her software. This is of course increasingly less the case, but 
that neither makes anyone a fool, nor does it make . comparable to 
~/.local/bin.)

> >> heroic attitude :-)
> >>
> >> *yes* you have lost and in doubt in this situation the
> >> interesting thing is how large the impact becomes
> >
> > Users of a multi-user system get to customize their system without having to bother a
> sysadmin, and without seeing
> > technical details of that's accompished mixed with their ~/Photos and
> ~/Documents.
>
>  on multi-user systems it is *intentional* that the user does *not* install
>  software at it's own and if this should be the case the admin *one time*
>  will add a directory to PATH and say "there you go" 
As Alec said, not necessarily. If you want this policy for your systems, 
you have the power to do so.
The users (or software they install) can, of course, edit their 
.bash_profile to change it right back.

> > What impact did *you* have in mind?
>
>  the *security* impact after "you have lost" happened 
In both cases, everything the user had access to is compromised, 
including .bash_profile itself. What other *security* impact did you 
have in mind?

-- 
Petr³

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 01.11.2013 13:00, schrieb Petr Viktorin:
>  On 11/01/2013 11:14 AM, Reindl Harald wrote:
> > the rootkit in /tmp/cp is in your path?
>  
>  If . would have been in $PATH and I happened to be in /tmp, then yes.
>  On the other hand if I install something in my home, it does not affect other users in
> any way.
>  
>  (As an aside: the old Unix security decisions assumed the user trusts his or her
> software. This is of course
>  increasingly less the case, but that neither makes anyone a fool, nor does it make .
> comparable to ~/.local/bin.) 
and because it is increasingly less the case we shoulkd be *very*
careful in extending PATH environment

> > on multi-user systems it is *intentional* that the user does
> *not* install
> > software at it's own and if this should be the case the admin *one time*
> > will add a directory to PATH and say "there you go"
>  
>  As Alec said, not necessarily. If you want this policy for your systems, you have the
> power to do so 
which works also in the other direction and users knowing about $HOME/.local/bin
most likely know about .bash_profile

>  The users (or software they install) can, of course, edit their
> .bash_profile to change it right back. 
if you really want to forbid it strictly they can't
chattr +i .bash_profile; chattr +i .bashrc

but we are talking about defaults

> >> What impact did *you* have in mind?
> >
> > the *security* impact after "you have lost" happened
>  
>  In both cases, everything the user had access to is compromised, including .bash_profile
> itself. What other
>  *security* impact did you have in mind? 
when i learned something about security than that the dangerous things are the
one which are *not* in your mind and that is why the environment should be
as tight as possible

example from the server world?

* vhost with no vulnerable scripts
* another vhost with a file inclusion vulnerability
* no open_basedir set in the vulnerable one
* attacker called a page with <?php code ?> in the URL and wrote "his
script"
* file inclusion vulnerability to the apache access log
* the so executed code modified scripts in the non vulnerable vhost
* later they placed PHP code in images
* http://www.phpclasses.org/blog/post/67-PHP-security-exploit-with-GIF-imag...
* finally they removed their scripts but made a mistake which was the only reason the
  forensic found what happened on the machine

i was not responsible for the server itself, but for the not vulerable CMS and
had to prove that not my CMS was the door for compromise the server and after
we found out what exactly happend i had to say "wow, respect"

*that* is what happens in security if someone comes with "show me the exact problem
you see"

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-11-01 13:16, Reindl Harald wrote:
>  Am 01.11.2013 13:00, schrieb Petr Viktorin:
> > In both cases, everything the user had access to is compromised, including
> .bash_profile itself. What other
> > *security* impact did you have in mind?
>  when i learned something about security than that the dangerous things are the
>  one which are *not* in your mind and that is why the environment should be
>  as tight as possible 
No. It should be the right trade-off between usabilty and
security. A 
thing which haven't a single answer, and seldom lends itself to being 
cocksure.

--alec

$HOME/.local/bin in $PATH

[drago01]

On Fri, Nov 1, 2013 at 10:48 AM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  Am 01.11.2013 10:38, schrieb drago01:
> > On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley <aph(a)redhat.com&gt; wrote:
> >> On 10/30/2013 10:27 AM, Alec Leamas wrote:
> >>> On 2013-10-30 11:23, Reindl Harald wrote:
> >>>> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>>>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>>>> Some kind of reference for the bad in having a well-known,
> hidden directory in the path?
> >>>>>> the *writeable for the user* is the problem
> >>>>> Any reference for this problem?
> >>>> what about consider the implications?
> >>>> do you really need a written reference for any security relevant fact?
> >>>> i can write one for you if you prefer links :-)
> >>>>
> >>> Well, the question is really if someone else out there share your
> >>> concerns about this.
> >>
> >> Why does it matter?  A hidden directory in everyone's path is obviously
> >> useful to an attacker, and (IMO) more useful to an attacker than to a user.
> >
> > The attacker needs to be able to write to your home directory to take
> > advantage of it.
> > And if he can do that (you lost) he has numerous other ways of doing it
>
>  so the people decided not put the current directory in the
>  PATH on Unix *for security reasons* decades ago must be
>  fools and if you would have been born as this happened you
>  would have told them "forget it, in that case you are lost" 
No because they have done it for a completely different reasons.
None of them was to protect from the attacker that can write to your
home directory.

$HOME/.local/bin in $PATH

[Andrew Haley]

On 11/01/2013 09:38 AM, drago01 wrote:
>  On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley <aph(a)redhat.com&gt;
> wrote:
> > On 10/30/2013 10:27 AM, Alec Leamas wrote:
> >> On 2013-10-30 11:23, Reindl Harald wrote:
> >>> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>>> Some kind of reference for the bad in having a well-known, hidden
> directory in the path?
> >>>>> the *writeable for the user* is the problem
> >>>> Any reference for this problem?
> >>> what about consider the implications?
> >>> do you really need a written reference for any security relevant fact?
> >>> i can write one for you if you prefer links :-)
> >>>
> >> Well, the question is really if someone else out there share your
> >> concerns about this.
> >
> > Why does it matter?  A hidden directory in everyone's path is obviously
> > useful to an attacker, and (IMO) more useful to an attacker than to a user.
>  
>  The attacker needs to be able to write to your home directory to
>  take advantage of it.  And if he can do that (you lost) he has
>  numerous other ways of doing it. 
That is true.  However, there is an advantage to this one for the
attacker: the user probably doesn't know it's there.

It's a matter of the attack surface: the 'sum of the different points
(the "attack vectors") where an unauthorized user (the "attacker")
can
try to enter.' [Wikipedia]

Having a writable and hidden directory in everyone's path increases
the attack surface.  Having the current working directory in
everyone's path increases the attack surface, etc, etc.  Defence in
depth is about reducing the attack surface.

Andrew.

$HOME/.local/bin in $PATH

[Miloslav Trmač]

On Fri, Nov 1, 2013 at 7:12 PM, Andrew Haley <aph(a)redhat.com&gt; wrote:
>  On 11/01/2013 09:38 AM, drago01 wrote:
> > The attacker needs to be able to write to your home directory to
> > take advantage of it.  And if he can do that (you lost) he has
> > numerous other ways of doing it.
>
>  That is true.  However, there is an advantage to this one for the
>  attacker: the user probably doesn't know it's there. 
I don't think this in practice matters _for security_[1]: Even the
users that know ~/bin exists are extremely unlikely to be regularly
checking its contents to see whether a malicious file hasn't been
added.

>  It's a matter of the attack surface: the 'sum of the
> different points
>  (the "attack vectors") where an unauthorized user (the "attacker")
> can
>  try to enter.' [Wikipedia] 
In all of the scenarios we've been talking about, the attack has
already _succeeded_; there is no longer any relevant attack surface
left.[2]
    Mirek

[1] It might matter for troubleshooting.
[2] Possible privilege escalations attacks to get root's or other
user's permissions are irrelevant to our discussion.

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 01.11.2013 20:55, schrieb Miloslav Trmač:
>  [1] It might matter for troubleshooting.
>  [2] Possible privilege escalations attacks to get root's or other
>  user's permissions are irrelevant to our discussion. 
[2] is very courageous (to say it nice) in the context we talk

$HOME/.local/bin in $PATH

[Chris Adams]

Once upon a time, Miloslav Trmač <mitr(a)volny.cz&gt; said:
>  I don't think this in practice matters _for security_[1]: Even
> the
>  users that know ~/bin exists are extremely unlikely to be regularly
>  checking its contents to see whether a malicious file hasn't been
>  added. 
And again, it isn't just directories in PATH.  How many users regularly
check their shell init scripts (.bash_profile, .bashrc), desktop
environment autostart files (.config/autostart, at least for MATE that
I'm running at the moment), etc.?  I'm pretty security-aware, but I
don't go examine all of that under normal conditions.  Checking the PATH
is a lot easier than checking all the rest of that.

I get that some don't like $HOME/.local/bin; that's fine, agree to
disagree (I don't really care one way or the other about this one).
However, don't try to make it about security; that just isn't really an
issue here, no matter how "obvious" you may feel it to be.
-- 
Chris Adams <linux(a)cmadams.net&gt;

$HOME/.local/bin in $PATH

[Miloslav Trmač]

On Fri, Nov 1, 2013 at 9:04 PM, Chris Adams <linux(a)cmadams.net&gt; wrote:
>  I get that some don't like $HOME/.local/bin; that's fine,
> agree to
>  disagree (I don't really care one way or the other about this one).
>  However, don't try to make it about security; that just isn't really an
>  issue here, no matter how "obvious" you may feel it to be. 
Exactly.  It's kind of ironic that I have ended up defending
~/.local/bin even though I don't like it, only because I want to keep
"security" discussions to be precise :)
    Mirek

$HOME/.local/bin in $PATH

[Christopher]

On Fri, Nov 1, 2013 at 5:38 AM, drago01 <drago01(a)gmail.com&gt; wrote:
>  On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley <aph(a)redhat.com&gt;
> wrote:
> > On 10/30/2013 10:27 AM, Alec Leamas wrote:
> >> On 2013-10-30 11:23, Reindl Harald wrote:
> >>> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>>> Some kind of reference for the bad in having a well-known, hidden
> directory in the path?
> >>>>> the *writeable for the user* is the problem
> >>>> Any reference for this problem?
> >>> what about consider the implications?
> >>> do you really need a written reference for any security relevant fact?
> >>> i can write one for you if you prefer links :-)
> >>>
> >> Well, the question is really if someone else out there share your
> >> concerns about this.
> >
> > Why does it matter?  A hidden directory in everyone's path is obviously
> > useful to an attacker, and (IMO) more useful to an attacker than to a user.
>
>  The attacker needs to be able to write to your home directory to take
>  advantage of it.
>  And if he can do that (you lost) he has numerous other ways of doing it. 
You seem to be saying that attackers don't make decisions based on the
probability of getting caught, or based on the level of visibility
their actions might incur. There's a reason why muggers tend to mug at
night, thieves are more likely to sneak in an unlocked door than break
a window, and malware renames files to look innocuous: the less
visible, the more effective they are able to not get caught and
continue to exploit.

Now, we could argue that ~/.local/bin is *just as* visible as ~/bin,
because they are both on the PATH, but please don't argue that because
attackers have choices, then all choices are equivalent. The former is
debatable (and can probably be measured with a simple user survey,
rather than speculated about), but the latter is simply not true.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

$HOME/.local/bin in $PATH

[drago01]

On Fri, Nov 1, 2013 at 11:54 PM, Christopher <ctubbsii(a)apache.org&gt; wrote:
>  On Fri, Nov 1, 2013 at 5:38 AM, drago01 <drago01(a)gmail.com&gt;
> wrote:
> > On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley <aph(a)redhat.com&gt; wrote:
> >> On 10/30/2013 10:27 AM, Alec Leamas wrote:
> >>> On 2013-10-30 11:23, Reindl Harald wrote:
> >>>> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>>>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>>>> Some kind of reference for the bad in having a well-known,
> hidden directory in the path?
> >>>>>> the *writeable for the user* is the problem
> >>>>> Any reference for this problem?
> >>>> what about consider the implications?
> >>>> do you really need a written reference for any security relevant fact?
> >>>> i can write one for you if you prefer links :-)
> >>>>
> >>> Well, the question is really if someone else out there share your
> >>> concerns about this.
> >>
> >> Why does it matter?  A hidden directory in everyone's path is obviously
> >> useful to an attacker, and (IMO) more useful to an attacker than to a user.
> >
> > The attacker needs to be able to write to your home directory to take
> > advantage of it.
> > And if he can do that (you lost) he has numerous other ways of doing it.
>
>  You seem to be saying that attackers don't make decisions based on the
>  probability of getting caught, or based on the level of visibility
>  their actions might incur. There's a reason why muggers tend to mug at
>  night, thieves are more likely to sneak in an unlocked door than break
>  a window, and malware renames files to look innocuous: the less
>  visible, the more effective they are able to not get caught and
>  continue to exploit.
>
>  Now, we could argue that ~/.local/bin is *just as* visible as ~/bin,
>  because they are both on the PATH, 
Sorry but I still don't by the visible argument. Do you really do
check what is inside ~/bin
before running every command? Even if you do that I do not need a
survey to claim that a
majority of user simply do not do that.

$HOME/.local/bin in $PATH

[Christopher]

On Sat, Nov 2, 2013 at 5:22 AM, drago01 <drago01(a)gmail.com&gt; wrote:
>  On Fri, Nov 1, 2013 at 11:54 PM, Christopher
> <ctubbsii(a)apache.org&gt; wrote:
> > On Fri, Nov 1, 2013 at 5:38 AM, drago01 <drago01(a)gmail.com&gt; wrote:
> >> On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley <aph(a)redhat.com&gt; wrote:
> >>> On 10/30/2013 10:27 AM, Alec Leamas wrote:
> >>>> On 2013-10-30 11:23, Reindl Harald wrote:
> >>>>> Am 30.10.2013 11:20, schrieb Alec Leamas:
> >>>>>> On 2013-10-30 10:58, Reindl Harald wrote:
> >>>>>>> Am 30.10.2013 10:53, schrieb Alec Leamas:
> >>>>>>>> Some kind of reference for the bad in having a
> well-known, hidden directory in the path?
> >>>>>>> the *writeable for the user* is the problem
> >>>>>> Any reference for this problem?
> >>>>> what about consider the implications?
> >>>>> do you really need a written reference for any security relevant
> fact?
> >>>>> i can write one for you if you prefer links :-)
> >>>>>
> >>>> Well, the question is really if someone else out there share your
> >>>> concerns about this.
> >>>
> >>> Why does it matter?  A hidden directory in everyone's path is obviously
> >>> useful to an attacker, and (IMO) more useful to an attacker than to a user.
> >>
> >> The attacker needs to be able to write to your home directory to take
> >> advantage of it.
> >> And if he can do that (you lost) he has numerous other ways of doing it.
> >
> > You seem to be saying that attackers don't make decisions based on the
> > probability of getting caught, or based on the level of visibility
> > their actions might incur. There's a reason why muggers tend to mug at
> > night, thieves are more likely to sneak in an unlocked door than break
> > a window, and malware renames files to look innocuous: the less
> > visible, the more effective they are able to not get caught and
> > continue to exploit.
> >
> > Now, we could argue that ~/.local/bin is *just as* visible as ~/bin,
> > because they are both on the PATH,
>
>  Sorry but I still don't by the visible argument. Do you really do
>  check what is inside ~/bin
>  before running every command? Even if you do that I do not need a
>  survey to claim that a
>  majority of user simply do not do that. 
I do, actually... because I put stuff there, so I inspect its contents
periodically when I do. However, my claim above is not about me. I did
not claim that a majority of users behave like me. What I said was,
that you could probably measure, by survey, whether or not the two
directories on the path were equally visible to users. I can say that
the two are not equally visible *to me*, but I'm not going to claim
that they are equally visible to the average user, or even the average
security-conscious user. I *suspect* they aren't equally visible to
certain significant subsets of users, but since it is probably
measurable, I'm suggesting a means to find it out instead of
speculating based on my own behavior.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

$HOME/.local/bin in $PATH

[Miloslav Trmač]

On Wed, Oct 30, 2013 at 10:23 AM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
> > If I can write to files you own, it doesn't matter if
> there's a
> > directory in the PATH or not.  I can write this to your .bash_profile:
> >
> >    /bin/mkdir $HOME/.bin 2> /dev/null
> >    echo 'echo "i could rm -rf ~/ here"' > $HOME/.bin/mkdir
> >    chmod +x $HOME/.bin/mkdir
> >    PATH=$HOME/.bin:$PATH
>
>  you can do this and that - but that's no valid argumentation
>  doing bad things in default setups and *at least* do not
>  place *hidden* diretories there, ther is a good reason why
>  software like rkhunter alerts if you have hidden directories
>  somewhere in /usr/bin/
>
>  there are three type of users
>
>  * people who care about security and know that there are
>    enough rough edges but smart enough to take this *not
>    as excuse* to create new ones 
That's not how security works.  To get actual security, you want the
design to make a _precise_ promise, and then implement it _100%
correctly_.  Not with "rough edges"; compose three implementations
with "rough edges" and the result gives you no security promise.

In this case, the security promise needs to be "the attacker can't
write to arbitrary files in your home directory"; if that is broken,
the existence of ~/.local/bin doesn't make any difference.


I agree ~/.local/bin is problematic for system administration and
troubleshooting, but that's not security.  And yes, the design is
known to have problems (multi-arch in shared home directories, same as
~/bin) - but now that it has been there for some time, we really can't
remove it without breaking user's existing setups, so it would need an
_extremely_ good reason.
    Mirek

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 30.10.2013 18:59, schrieb Miloslav Trmač:
>  On Wed, Oct 30, 2013 at 10:23 AM, Reindl Harald
> <h.reindl(a)thelounge.net&gt; wrote:
> >> If I can write to files you own, it doesn't matter if there's a
> >> directory in the PATH or not.  I can write this to your .bash_profile:
> >>
> >>    /bin/mkdir $HOME/.bin 2> /dev/null
> >>    echo 'echo "i could rm -rf ~/ here"' > $HOME/.bin/mkdir
> >>    chmod +x $HOME/.bin/mkdir
> >>    PATH=$HOME/.bin:$PATH
> >
> > you can do this and that - but that's no valid argumentation
> > doing bad things in default setups and *at least* do not
> > place *hidden* diretories there, ther is a good reason why
> > software like rkhunter alerts if you have hidden directories
> > somewhere in /usr/bin/
> >
> > there are three type of users
> >
> > * people who care about security and know that there are
> >   enough rough edges but smart enough to take this *not
> >   as excuse* to create new ones
>  
>  That's not how security works.  To get actual security, you want the
>  design to make a _precise_ promise, and then implement it _100%
>  correctly_.  Not with "rough edges"; compose three implementations
>  with "rough edges" and the result gives you no security promise. 
no *that is* how security works
100% security is simply impossible

>  In this case, the security promise needs to be "the attacker
> can't
>  write to arbitrary files in your home directory" 
which is not possible at all, any application running with your
user can write in your home directory and any security relevant
bug in that application may result in changes
__________________________

even if my english is not perfect i try to explain some basics now
the only remeining question the impact of this possible changes

* have one writeable places for executeables -> the attack needs to try exactly this
* have three writeable places for executeables -> the attack needs one out of three

and no, you can't imagine an attack like "hey i have a sehll now and
try around where i can compromise your setup" - in most cases after
a buffer overlow and such things you have *one* chance to execture
your code before the applications crashs

$HOME/.local/bin in $PATH

[Bruno Wolff III]

On Wed, Oct 30, 2013 at 19:15:11 +0100,
   Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
> which is not possible at all, any application running with your
> user can write in your home directory and any security relevant
> bug in that application may result in changes 
That doesn't have to be the case. selinux can be used to prevent some 
applications from doing that.

$HOME/.local/bin in $PATH

[Reindl Harald]

Am 30.10.2013 19:51, schrieb Bruno Wolff III:
>  On Wed, Oct 30, 2013 at 19:15:11 +0100,
>  Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
> >
> > which is not possible at all, any application running with your
> > user can write in your home directory and any security relevant
> > bug in that application may result in changes
>  
>  That doesn't have to be the case. selinux can be used to prevent some applications
> from doing that 
and here again the word *some* which shows 100% security is impossible
anybody really have security as his daily job is knowing that

that's the reason why security is layered and finally ends in
offer as less as possible attack vectors all over these layers

* firewall
* network
* kernel
* OS userland
* filesystem permissions
* default settings
* applications

since the only way to gain 100% security is to remove the network cable
and lock USB/Firewire completly you are limited in make any of these
layers as secure as possible by not damage normal operations

because attacks these days are so much widespreaded and applications way
too complex that any knowledgable person would avoid to say "this is
for sure secure" fro whatever piece of software you can only find
a good balance between as secure as possible and no longer working

any software working with untrusted data has this problem and in
doubt there is only few software not working with untrusted data
because you hardly can be sure that a image, office-document, video
or PDF or whatever file received from your best friend was not already
modified on his machine to attack whatever applications without take notice

a few years ago people called me a paranoid idiot because i statet all
this multiple times, but after the news of the last 6 months most of
these people got very silent and you can be sure that it does not
need the NSA/CIA to take advantage of security holes

$HOME/.local/bin in $PATH

[drago01]

On Wed, Oct 30, 2013 at 7:15 PM, Reindl Harald <h.reindl(a)thelounge.net&gt; wrote:
>  and no, you can't imagine an attack like "hey i have a sehll
> now and
>  try around where i can compromise your setup" - in most cases after
>  a buffer overlow and such things you have *one* chance to execture
>  your code before the applications crashs 
No. A typical buffer overflow attack is used to either spawn a local
shell or a reverse shell using execve().

$HOME/.local/bin in $PATH

[Chris Adams]

Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
>  you can do this and that - but that's no valid argumentation
>  doing bad things in default setups 
But you are calling it "bad" with no real argument except repitition.
I've shown that it is not _any_ worse for security.

>  *at least* do not
>  place *hidden* diretories there, ther is a good reason why
>  software like rkhunter alerts if you have hidden directories
>  somewhere in /usr/bin/ 
There's a vast difference between $HOME/.local/bin and a dot-directory
under /usr/bin (where nothing installs them on normal systems but root
kits often do).

-- 
Chris Adams <linux(a)cmadams.net&gt;

$HOME/.local/bin in $PATH

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/29/2013 09:03 PM, Chris Adams wrote:
>  Once upon a time, Reindl Harald <h.reindl(a)thelounge.net&gt; said:
> > [root@srv-rhsoft:~]$ mkdir test i could rm -rf ~/ here
> > 
> > [root@srv-rhsoft:~]$ cat /usr/local/bin/mkdir #!/bin/bash echo "i could
> > rm -rf ~/ here"
>  
>  If I can write to files you own, it doesn't matter if there's a directory
>  in the PATH or not.  I can write this to your .bash_profile:
>  
>  /bin/mkdir $HOME/.bin 2> /dev/null echo 'echo "i could rm -rf ~/
> here"' >
>  $HOME/.bin/mkdir chmod +x $HOME/.bin/mkdir PATH=$HOME/.bin:$PATH
>  
>  Sure, it might not take effect immediately, but that's probably not the 
>  point (I can't depend on you running "mkdir" in a shell at any particular
>  point in time anyway).  You wouldn't gain anything security-wise by
>  excluding a user-writable directory in PATH.
>  
>  In fact, having a "known" ~/.local/bin could allow for a more restrictive
>  SELinux policy on that directory that doesn't let arbitrary programs
>  running as the user write there (don't know if that is the case though).
>   
 matchpathcon /home/dwalsh/bin /home/dwalsh/.local/bin
/home/dwalsh/bin	staff_u:object_r:home_bin_t:s0
/home/dwalsh/.local/bin	staff_u:object_r:home_bin_t:s0


We are doing this in some form, although more towards, the only files in the
users homedir is allowed to execute is in the home_bin_t directory.

We do try to block confined apps from writing to user_home_t which is most
files in ~ and also home_bin_t.

The only reference to home_bin_t on the target right now is the following.

 sesearch -A -t home_bin_t -c file | grep home_bin_t
   allow postfix_local_t home_bin_t : file { ioctl read getattr execute
execute_no_trans open } ;
   allow procmail_t home_bin_t : file { ioctl read getattr execute
execute_no_trans open } ;

Of course lots of user domains and unconfined domains are allowed to write to
home_bin_t.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJxHH0ACgkQrlYvE4MpobOjDwCfaMO1bL17awLmc+F+DbWv44it
> IEwAmgKT5WIdNege1rE+IS8ISXGLJlca
> =Fc9n
> -----END PGP SIGNATURE-----

$HOME/.local/bin in $PATH

[Przemek Klosowski]

On 10/28/2013 02:08 PM, Sérgio Basto wrote:
>  On Seg, 2013-10-28 at 11:28 -0400, Paul Wouters wrote:
> > On Mon, 28 Oct 2013, Michael Schwendt wrote:
> >> Exists for a longer time already, added in of the .fc16 builds:
> >>
> >> * Tue Jun 07 2011 Roman Rakus <…> - 4.2.10-3
> >> - Added $HOME/.local/bin to PATH in .bash_profile (#699812)
> > An invisible directory in everyone's PATH. That's rather unfortunate.
> >
> > When will this be removed?
>  I agree, I don't have $HOME/.local/bin directory , but bug #699812 ,have
>  request the opposite ... , I don't see any good reason there but ...
>  
I agree that it smells like trouble security-wise. The original reason 
given was that it is required by XDG, but I don't understand the utility 
of ~/.local/bin : is it about separating local-arch binaries from common 
storage?

$HOME/.local/bin in $PATH

[Matthew Miller]

On Mon, Oct 28, 2013 at 11:28:01AM -0400, Paul Wouters wrote:
>  >* Tue Jun 07 2011 Roman Rakus <…> - 4.2.10-3
>  >- Added $HOME/.local/bin to PATH in .bash_profile (#699812)
>  An invisible directory in everyone's PATH. That's rather unfortunate. 
Okay, I'll bite. Why is this _particularly_ unfortunate? The directory isn't
actually "invisible", just hidden. There are plenty of hidden files in home
directories which are executed all of the time, like ~/.bashrc and
~/.bash_profile, and whatever X startup scripts your environment uses.

Now, if you want to argue that nothing user-writable should be in $PATH by
default, I can maybe see your point, although I also see the convenience
trade-off, and a) that ship has long sailed and b) no one seems to be
arguing that.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

$HOME/.local/bin in $PATH

[Jared K. Smith]

On Mon, Oct 28, 2013 at 4:05 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt;wrote:

>  Okay, I'll bite. Why is this _particularly_ unfortunate? The
> directory
>  isn't
>  actually "invisible", just hidden.
>  
[snip]


>  Now, if you want to argue that nothing user-writable should be in
> $PATH by
>  default, I can maybe see your point
>  
For me, it's the intersection of the two -- the point that it's hidden
*and* user-writable *and* comes earlier in the path than the system
directories.  Speaking only for myself, I could probably hold my nose and
be OK with any one of those things in isolation, but put them all together,
and it starts to smell funny.

--
Jared Smith

$HOME/.local/bin in $PATH

[Stephen John Smoogen]

On 28 October 2013 14:05, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:

>  On Mon, Oct 28, 2013 at 11:28:01AM -0400, Paul Wouters wrote:
>  > >* Tue Jun 07 2011 Roman Rakus <…> - 4.2.10-3
>  > >- Added $HOME/.local/bin to PATH in .bash_profile (#699812)
>  > An invisible directory in everyone's PATH. That's rather unfortunate.
>
>  Okay, I'll bite. Why is this _particularly_ unfortunate? The directory
>  isn't
>  actually "invisible", just hidden. There are plenty of hidden files in home
>  directories which are executed all of the time, like ~/.bashrc and
>  ~/.bash_profile, and whatever X startup scripts your environment uses.
>
>  Now, if you want to argue that nothing user-writable should be in $PATH by
>  default, I can maybe see your point, although I also see the convenience
>  trade-off, and a) that ship has long sailed and b) no one seems to be
>  arguing that.
>
>
>  
There are hidden files which are executable but are well known and
documented. However directories of executable that are not user visible are
the prime places that hackers like to drop stuff off in. Add in something
that is 'non-standard' in that ~/local/bin and ~/bin then you end up with a
lot of problems from auditors finding a place to checkmark failure to
surprise in just general sysadmins.




>  --
>  Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <
>  mattdm(a)fedoraproject.org&gt;
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  


-- 
Stephen J Smoogen.

$HOME/.local/bin in $PATH

[Matthias Runge]

On 10/28/2013 09:05 PM, Matthew Miller wrote:
>  On Mon, Oct 28, 2013 at 11:28:01AM -0400, Paul Wouters wrote:
> >> * Tue Jun 07 2011 Roman Rakus <…> - 4.2.10-3
> >> - Added $HOME/.local/bin to PATH in .bash_profile (#699812)
> > An invisible directory in everyone's PATH. That's rather unfortunate.
>  
>  Okay, I'll bite. Why is this _particularly_ unfortunate? The directory isn't
>  actually "invisible", just hidden. There are plenty of hidden files in home
>  directories which are executed all of the time, like ~/.bashrc and
>  ~/.bash_profile, and whatever X startup scripts your environment uses.
>   
Another reason, why this is unfortunate is:

We're supporting multiple arches. User directories are for user data.
Esp. it is intended to share user directories between computers. So,
it's absolutely ok to share between multiple arches, such as i386, arm, etc.
When putting arch specific data in a shared dir, all kinds of stuff may
happen; in most cases, applications just crash.

Matthias

$HOME/.local/bin in $PATH

[Ralf Corsepius]

On 10/29/2013 08:07 AM, Matthias Runge wrote:
>  On 10/28/2013 09:05 PM, Matthew Miller wrote:
> > On Mon, Oct 28, 2013 at 11:28:01AM -0400, Paul Wouters wrote:
> >>> * Tue Jun 07 2011 Roman Rakus <…> - 4.2.10-3
> >>> - Added $HOME/.local/bin to PATH in .bash_profile (#699812)
> >> An invisible directory in everyone's PATH. That's rather unfortunate.
> > Okay, I'll bite. Why is this _particularly_ unfortunate? The directory isn't
> > actually "invisible", just hidden. There are plenty of hidden files in
> home
> > directories which are executed all of the time, like ~/.bashrc and
> > ~/.bash_profile, and whatever X startup scripts your environment uses.
> >
>  Another reason, why this is unfortunate is:
>
>  We're supporting multiple arches. User directories are for user data. 
No, user
directories are not restricted to data. A user may put anything 
into them.

>  Esp. it is intended to share user directories between computers. So,
>  it's absolutely ok to share between multiple arches, such as i386, arm, etc.
It's not limited to architectures. Users may even share their homes 
across different OSes (Consider nfs-mounted home in a heterogenous network).
However, coping with the issues related to this is up to the user rsp. 
the "conventions" of his local environment (network).

As such conventions are beyond the scope of a linux distro, it's a bad 
idea to let packages add PATHs underneath of $HOME.

Ralf

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-10-29 10:56, Ralf Corsepius wrote:
>  On 10/29/2013 08:07 AM, Matthias Runge wrote:
> > On 10/28/2013 09:05 PM, Matthew Miller wrote:
> >> On Mon, Oct 28, 2013 at 11:28:01AM -0400, Paul Wouters wrote:
> >>>> * Tue Jun 07 2011 Roman Rakus <…> - 4.2.10-3
> >>>> - Added $HOME/.local/bin to PATH in .bash_profile (#699812)
> >>> An invisible directory in everyone's PATH. That's rather
> unfortunate.
> >> Okay, I'll bite. Why is this _particularly_ unfortunate? The 
> >> directory isn't
> >> actually "invisible", just hidden. There are plenty of hidden files 
> >> in home
> >> directories which are executed all of the time, like ~/.bashrc and
> >> ~/.bash_profile, and whatever X startup scripts your environment uses.
> >>
> > Another reason, why this is unfortunate is:
> >
> > We're supporting multiple arches. User directories are for user data.
>  No, user directories are not restricted to data. A user may put 
>  anything into them.
>
> > Esp. it is intended to share user directories between computers. So,
> > it's absolutely ok to share between multiple arches, such as i386, 
> > arm, etc.
>  It's not limited to architectures. Users may even share their homes 
>  across different OSes (Consider nfs-mounted home in a heterogenous 
>  network).
>  However, coping with the issues related to this is up to the user rsp. 
>  the "conventions" of his local environment (network). 
+1.

>  As such conventions are beyond the scope of a linux distro, it's a bad 
>  idea to let packages add PATHs underneath of $HOME.
>
>  Ralf
>  
Indeed. But isn't the primary usecase here other sw installed by user 
and not packages? Since such sw already have a defined convention for 
data (~/.local/share), it makes a lot of sense to use ~/.local/bin as 
sort of "personal %_bindir" while installing - it makes ~/.local to a 
sane prefix installation-wise.

That said, if visibility is crucial ~/bin and ~/.local/bin could be 
symlinked as someone pointed out earlier in this thread. ~/.local/bin 
could perhaps be seen just as an installation view of $HOME. The 
arguments for hiding the executable files in user dialogues does not 
really convince me.

BTW, don't we also lack a default, user-controlled directory for 
manpages?  Shouldn't  ~/.local/share/man be part of user's default 
MANPATH? Same usecase, basically same solution...

--alec

$HOME/.local/bin in $PATH

[Alec Leamas]

On 2013-10-29 11:44, Alec Leamas wrote:
>  [cut] 
>  BTW, don't we also lack a default, user-controlled directory for
>
>  manpages?  Shouldn't  ~/.local/share/man be part of user's default 
>  MANPATH? Same usecase, basically same solution...
>  
[Answering myself...] We, we don't lack that. As of f20, this  seems to 
be fixed. Sorry for that noise.

--alec

[T.C. Hollingsworth]

On Sat, Oct 26, 2013 at 4:10 PM, Sandro Mani <manisandro(a)gmail.com&gt; wrote:
>  Hi,
>
>  I just noticed that my rawhide installation, which was originally installed
>  when F18 was rawhide in summer 2012 and upgraded since, has
>
>
> PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
>
>  On a fresh rawhide installation, I get
>
>
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
>
>  So, the order of /bin /usr/bin /usr/local/bin is reversed. Who is screwing
>  up the order?
>  - /etc/profile, /etc/bashrc and /etc/profile.d/* are identical between the
>  "old" and the "new" installations
>  - strings /bin/bash | grep /bin gives me the same output in both cases
>  - my .bashrc and .bash_profile are harmless (i.e.
>  PATH=$PATH:$HOME/.local/bin:$HOME/bin) 
Since it's not coming from /etc/profile or our .bashrc, I wonder if
it's coming from our desktop environment setup or something.

Let's check locally, then ssh into the same system and see if it's the same.

[tc@zathras]~% echo $PATH
/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/bin:/usr/bin:/usr/local/bin:/home/tc/bin:/usr/local/sbin:/usr/sbin
[tc@zathras]~% ssh localhost
Last login: <snipped>
[tc@zathras]~% echo $PATH
/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/home/tc/bin:/usr/local/sbin:/usr/sbin

Nope, notice that locally /bin is in $PATH, but when I ssh into the
same system, it isn't.  Where's it coming from?

% grep PATH /usr/bin/startkde
# in case we have been started with full pathname spec without being in PATH
  case $PATH in
    *) PATH=$bindir:$PATH; export PATH;

% grep bindir /usr/bin/startkde
bindir=`echo "$0" | sed -n 's,^\(/.*\)/[^/][^/]*$,\1,p'`
if [ -n "$bindir" ]; then
  qbindir=`$bindir/kde4-config --qt-binaries`
  qdbus=$qbindir/qdbus
    $bindir|$bindir:*|*:$bindir|*:$bindir:*) ;;
    *) PATH=$bindir:$PATH; export PATH;;

Hmm, that looks like it might be it.  So I added an `echo $bindir >
/tmp/bindir` to that script to see if it's not just a red herring.

% cat /tmp/bindir
/bin

Yup, that's it.

https://bugzilla.redhat.com/show_bug.cgi?id=1023999

Might want to check your desktop environment's start script too, if
it's different.

-T.C.

[Reindl Harald]

Am 28.10.2013 15:39, schrieb T.C. Hollingsworth:
>  Nope, notice that locally /bin is in $PATH, but when I ssh into the
>  same system, it isn't.  Where's it coming from? 
SSH has a hardcoded PATH for security reasons unless you configure both,
.bashrc and .bash_profile to have a non-hardcoded for interactive
as well as non-interactive shells

i wrote sometime ago a bugreport that it still has /usr and /sbin in this
hardcoded path which is nonsense after UsrMove and that was fixed

[Sandro Mani]

On 28.10.2013 15:39, T.C. Hollingsworth wrote:
>  On Sat, Oct 26, 2013 at 4:10 PM, Sandro Mani
> <manisandro(a)gmail.com&gt; wrote:
> > Hi,
> >
> > I just noticed that my rawhide installation, which was originally installed
> > when F18 was rawhide in summer 2012 and upgraded since, has
> >
> >
> PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
> >
> > On a fresh rawhide installation, I get
> >
> >
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/sandro/.local/bin:/home/sandro/bin
> >
> > So, the order of /bin /usr/bin /usr/local/bin is reversed. Who is screwing
> > up the order?
> > - /etc/profile, /etc/bashrc and /etc/profile.d/* are identical between the
> > "old" and the "new" installations
> > - strings /bin/bash | grep /bin gives me the same output in both cases
> > - my .bashrc and .bash_profile are harmless (i.e.
> > PATH=$PATH:$HOME/.local/bin:$HOME/bin)
>  Since it's not coming from /etc/profile or our .bashrc, I wonder if
>  it's coming from our desktop environment setup or something.
>
>  Let's check locally, then ssh into the same system and see if it's the same.
>
>  [tc@zathras]~% echo $PATH
>
> /usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/bin:/usr/bin:/usr/local/bin:/home/tc/bin:/usr/local/sbin:/usr/sbin
>  [tc@zathras]~% ssh localhost
>  Last login: <snipped>
>  [tc@zathras]~% echo $PATH
>
> /usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/home/tc/bin:/usr/local/sbin:/usr/sbin
>
>  Nope, notice that locally /bin is in $PATH, but when I ssh into the
>  same system, it isn't.  Where's it coming from?
>
>  % grep PATH /usr/bin/startkde
>  # in case we have been started with full pathname spec without being in PATH
>     case $PATH in
>       *) PATH=$bindir:$PATH; export PATH;
>
>  % grep bindir /usr/bin/startkde
>  bindir=`echo "$0" | sed -n 's,^\(/.*\)/[^/][^/]*$,\1,p'`
>  if [ -n "$bindir" ]; then
>     qbindir=`$bindir/kde4-config --qt-binaries`
>     qdbus=$qbindir/qdbus
>       $bindir|$bindir:*|*:$bindir|*:$bindir:*) ;;
>       *) PATH=$bindir:$PATH; export PATH;;
>
>  Hmm, that looks like it might be it.  So I added an `echo $bindir >
>  /tmp/bindir` to that script to see if it's not just a red herring.
>
>  % cat /tmp/bindir
>  /bin
>
>  Yup, that's it.
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1023999
>
>  Might want to check your desktop environment's start script too, if
>  it's different.
>
>  -T.C. 
Aha, that's interesting! Indeed my "oldrawhide" box is running
kde and 
my "newrawhide" box is running gnome. Thanks for the bugreport!

Sandro