On 7.7.2014 14:07, Josef Reidinger wrote:
On Mon, 07 Jul 2014 14:01:15 +0200 Lukas Ocilka
wrote: Hi fellow developers :)
Fourteen days ago, I had an issue to fix: Installer was calling /bin/rm but there was none - it's been already moved to /usr/bin/rm [#1]. Object /bin/rm should have been linking to /usr/bin/rm. In fact, the bug has been most probably caused by a broken build or installer DVD or maybe inst-sys build.
But this has shown how fragile might be a code that uses obsolete paths [#2], [#3]. So, please, next time you (or me) add a code which calls some binaries, let's make sure it uses the `currently` right path. Let's use the /usr/* whenever it's possible.
Many people are asking: Should I change all the code now? The answer is: No, just when you touch it anyway, make sure you change it the right way. It's similar to replacing Builtins.* with with their Ruby fellows, e.g. Builtins.y2milestone -> log.info.
Thanks in advance Lukas
#1 https://github.com/yast/yast-installation/pull/217 #2 https://en.opensuse.org/openSUSE:Usr_merge #3 http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
PS: Please correct me if I have written anything wrong :)
I have general question and I think answer to it should be somewhere written as documented decision.
Why we use absolute path to binary? I think proper set PATH in environment should be goal and use common path. Also from security point of view it is quite useless because if PATH is attacked, then also any real root action is attacked.
For me it is more native to write "rm -rf /" and not "/usr/bin/rm -rf /".
Sure, I myself also prefer the shorter way, but I think it was because of security. Let's ask our security expert if this is really the case, or whether it has changed meanwhile. Thomas, please, have a look. Thanks in advance Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org