On Thu, 28 Jul 2011 13:00:28 +0100 "Bryn M. Reeves" <bmr@xxxxxxxxxx> wrote: > On 07/28/2011 12:54 PM, Bernd Stramm wrote: > > On Thu, 28 Jul 2011 11:24:48 +0100 > > "Bryn M. Reeves" <bmr@xxxxxxxxxx> wrote: > >> There are already quite a few things that may place executables > >> under . prefixed paths in home. Java web start (javaws) for > >> instance will install an entire jre under .java/deployment/cache, > >> wine has for many years installed Windows executables (that can be > >> executed by the system) under .wine, browser plugins may be > >> installed to .mozilla/plugins and are just as capable of > >> performing "evil" actions as an executable (e.g. drop a malicious > >> plugin that hijacks some common MIME types, do your $evil and then > >> wrap the intended plugin). > >> > >> There are various other examples - on an older release I find 171 > >> such files under ~/: > >> > >> $ find $(l. | egrep -v '\.$|\.\.$') -type f -perm /111 | wc -l > >> 171 > > > > This is no excuse to add to a bad habit. > > I'm not using it as an excuse for anything but I do think it is > evidence that the security implications being bandied around in this > thread are rather overblown; as others have said an attacker that can > write to these locations is /already/ a problem. > > Using ~/.local (or any other path in home) doesn't make that any > better or worse. It is nevertheless an *added* avenue to do some phishing. And for what benefit? 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. What is also wrong is the way this supposedly got into the standard - a few casual remarks by a grand total of 2 people in a BZ, and all of a sudden it is part of a standard. That seems sloppy. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
