$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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3891 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20131030/4b2c1bd9/attachment.bin>