On Thu, 28 Jul 2011 14:35:27 +0100
"Bryn M. Reeves" <bmr(a)redhat.com> wrote:
On 07/28/2011 01:22 PM, Bernd Stramm wrote:
> On Thu, 28 Jul 2011 13:00:28 +0100
> "Bryn M. Reeves" <bmr(a)redhat.com> wrote:
> It is nevertheless an *added* avenue to do some phishing. And for
> what benefit?
No, it's not; at the very most it's making something very slightly
less noticeable but even that is a weak and flawed argument.
It is one additional avenue. Hence "added".
If your security relies on spotting that a malicious user has placed
a rogue binary in ~/bin you're already hosed.
My security does not rely on it, but my security does include looking
there if something funny is going on. Now I am suppose to look in
an additinal place, that was added quietly. Someone decided to change
where to look for executables in my $HOME. That is uncalled for.
> Adding a hidden directory to $PATH will cause people do filter it
> out from their $PATH. This leads to more messy use environments,
> not to cleaner ones as is the original purpose of this whole thing.
>
> No, hidden directories should not be in $PATH. If somebody put that
> in their standard, those folks should change their standard.
> Standards can define things that are wrong, and this is one such
> case.
I'm not especially attached to ~/.local/bin being in PATH (although I
do happen to think the approach used by python for --user
installations is an elegant solution).
This whole thread is about ~/.local/bin. I see it adding to the mess
found in $HOME, as opposed to cleaning things up. Shoving the mess
under a rug is not cleaning.