Re: $HOME/.local/bin in $PATH
On Fri, Nov 1, 2013 at 11:54 PM, Christopher ctubb...@apache.org wrote: On Fri, Nov 1, 2013 at 5:38 AM, drago01 drag...@gmail.com wrote: On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley a...@redhat.com 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley a...@redhat.com 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
Am 01.11.2013 10:38, schrieb drago01: On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley a...@redhat.com 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 a...@redhat.com 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³ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
2013/11/1 Reindl Harald h.rei...@thelounge.net: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 a...@redhat.com 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Fri, Nov 1, 2013 at 10:48 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 01.11.2013 10:38, schrieb drago01: On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley a...@redhat.com 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 a...@redhat.com 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³ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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-images.html * 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On 11/01/2013 09:38 AM, drago01 wrote: On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley a...@redhat.com 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Fri, Nov 1, 2013 at 7:12 PM, Andrew Haley a...@redhat.com 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
Once upon a time, Miloslav Trmač m...@volny.cz 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Fri, Nov 1, 2013 at 9:04 PM, Chris Adams li...@cmadams.net 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Fri, Nov 1, 2013 at 5:38 AM, drago01 drag...@gmail.com wrote: On Fri, Nov 1, 2013 at 10:26 AM, Andrew Haley a...@redhat.com 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Thu, Oct 31, 2013 at 10:01 AM, Nicolas Mailhot nicolas.mail...@laposte.net 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
Am 30.10.2013 02:03, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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.rei...@thelounge.net 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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.rei...@thelounge.net 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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.rei...@thelounge.net 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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.rei...@thelounge.net 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 :-) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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.rei...@thelounge.net 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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.rei...@thelounge.net 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+be+owned+by+root 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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.rei...@thelounge.net 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+be+owned+by+root 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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.rei...@thelounge.net 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+be+owned+by+root 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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.rei...@thelounge.net 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+be+owned+by+root 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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³ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Wed, Oct 30, 2013 at 6:27 AM, Alec Leamas leamas.a...@gmail.com 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.rei...@thelounge.net 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On 2013-10-30 15:05, Christopher wrote: On Wed, Oct 30, 2013 at 6:27 AM, Alec Leamas leamas.a...@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/29/2013 09:03 PM, Chris Adams wrote:
Once upon a time, Reindl Harald h.rei...@thelounge.net 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/binstaff_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-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Wed, Oct 30, 2013 at 10:23 AM, Reindl Harald h.rei...@thelounge.net 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
Am 30.10.2013 18:59, schrieb Miloslav Trmač: On Wed, Oct 30, 2013 at 10:23 AM, Reindl Harald h.rei...@thelounge.net 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Wed, Oct 30, 2013 at 19:15:11 +0100, Reindl Harald h.rei...@thelounge.net 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
Am 30.10.2013 19:51, schrieb Bruno Wolff III: On Wed, Oct 30, 2013 at 19:15:11 +0100, Reindl Harald h.rei...@thelounge.net 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Wed, Oct 30, 2013 at 7:15 PM, Reindl Harald h.rei...@thelounge.net 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(). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
Once upon a time, Reindl Harald h.rei...@thelounge.net 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
Once upon a time, Reindl Harald h.rei...@thelounge.net 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Tue, Oct 29, 2013 at 2:06 PM, Chris Adams li...@cmadams.net wrote: Once upon a time, Reindl Harald h.rei...@thelounge.net 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
Am 30.10.2013 01:11, schrieb drago01: On Tue, Oct 29, 2013 at 2:06 PM, Chris Adams li...@cmadams.net wrote: Once upon a time, Reindl Harald h.rei...@thelounge.net 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* signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
Once upon a time, Reindl Harald h.rei...@thelounge.net 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 li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Mon, 28 Oct 2013 19:51:06 +0100 Michael Schwendt mschwe...@gmail.com 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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
Am 28.10.2013 20:00, schrieb Michael Ekstrand: On Mon, 28 Oct 2013 19:51:06 +0100 Michael Schwendt mschwe...@gmail.com 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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'] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Mon, Oct 28, 2013 at 4:05 PM, Matthew Miller mat...@fedoraproject.orgwrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On 28 October 2013 14:05, Matthew Miller mat...@fedoraproject.org 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 ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Mon, 28 Oct 2013 20:30:05 + Sérgio Basto ser...@serjux.com 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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
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'. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: $HOME/.local/bin in $PATH
On Mon, Oct 28, 2013 at 5:50 PM, Reindl Harald h.rei...@thelounge.net 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
