Re: $HOME/.local/bin in $PATH

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2013-10-30 15:05, Christopher wrote:
On Wed, Oct 30, 2013 at 6:27 AM, Alec Leamas <leamas.alec@xxxxxxxxx> 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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux