Portál AbcLinuxu, 24. října 2025 19:41
Nový VIM verze 7 slibuje zajímavé funkce, mimo jiné code completion pro řadu jazyků včetně RUBY. Implementace code completion není v případě RUBY nic snadného, tak jsem byl zvědavý, jak si s tím autor VIMu poradil. Dnes jsem si to vyzkoušel vlastníma rukama a nevěřil jsem vlastním očím...
Out of the box mi code completion pro ruby nefungovava (byly v tom moje úpravy konfigurace pro VIM 6), tak jsem se jal číst dokumentaci... Uzel nápovědy "ft-ruby-omni" obsahuje text:
Notes: - Vim will load/evaluate code in order to provide completions. This may cause some code execution, which may be a concern.
Tahle věta nám vlastně říká, jak je code completion udělán -- oni ten kód VYKONÁVAJÍ. Chvíli jsem nevěřícně kulil oči "may be a concern" -- to je poněkud eufemisticky řečeno! Zavětřil jsem zásadní bezpečnostní problém.
Pak si říkám, že v RUBY jsou přece prostředky, jak se s takovou situací vyrovnat. No a pak jsem si to vyzkoušel... a málem jsem spadl ze židle: je to tak, použitím code completion ve VIMu si třeba můžete smazat disk.
Demonstrace:
Mějme zdrojový soubor a.rb:
system('echo vim je pako > /tmp/pako')
class MyTest
def test
return 1
end
end
Porom mějme zdrojový kód, který editujeme, třeba b.rb:
require 'a'
t = MyTest.new
t.t
Pokud nyní umístíte kursor na konec posledního řádku souboru b.rb a stiskněte CTRL-X-O (code completion), VIM vám korektně nabítne metodu "test". Jenže při tom také vytvoří soubor /tmp/pako s obsahem "vim je pako"...
Co k tomu dodat? Zneužití se přímo nabízí, nemluvě o tom, že ke škodě může dojít i omylem.
Někdy je méně více...
Tiskni
Sdílej:
require "my-evil-script.rb", vim se přepne do ruby-mode, a v site-packages se objeví váš zákeřný exploit, aby jej vim mohl spustit?
system("echo #{$:.inspect} >> /tmp/zde_je_pako")
.
3. krok (pokud vám to ani teď nedocvaklo) - zamyslete se nad tím, jestli je třeba možné, že by někdo pustil VIM z adresáře /tmp/.
4. krok a) pokud vám to už docvaklo, nasypte si popel na hlavu a příště před psaním ironického příspěvku přemýšlejte, b) pokud se cvaknutí stále nedostavilo, změňte povolání
I ten loading kvůli zjištění názvů metod by měl jít celkem rozumně zasandboxovat. Jen by se o to měl přičinit autor...
".", je to jistý bezpečnostní nedostatek, ovšem pro Ruby, ne pro Vim.
2) Pusťte si Bash. Pod rootem napište echo >/etc/povolny_je_pako, a stiskněte ENTER (ta velká klávesa napravo se zalomenou šipkou). Ha! bash je děravý.
3) To samozřejmě možné je, ale netuším co tím chcete dokázat.
4) Myslím že vaše rady nebudu brát příliš vážně.
1) pokud má Ruby jako prioritní search path pro moduly ".", je to jistý bezpečnostní nedostatek, ovšem pro Ruby, ne pro Vim.
Jako prioritní ne, ale v serch path '.' má a to stačí. A problém VIMu to je, protože mluvíme o variantě, kdy je VIM linkován s Ruby a VIM nevhodným způsobem Ruby používá (nenastavuje $SAFE).
2) Pusťte si Bash. Pod rootem napište echo >/etc/povolny_je_pako, a stiskněte ENTER (ta velká klávesa napravo se zalomenou šipkou). Ha! bash je děravý.
No to je dost mizerný vtip a ještě horší přirovnání.
3) To samozřejmě možné je, ale netuším co tím chcete dokázat.Třeba to, že exploit zranitelnosti, kterou jsem popsal je poměrně proveditelný.
Jinak než z již vykonaného kódu se v jazycích jako Python, Ruby a Lisp doplňovat prostě nedá. Používám hlavně Slime, takže mi to vlastně ani nevadí a už mi přijde úplně přirozené, že completion bere v úvahu kód, který jsem již napsal, načetl a vyzkoušel. (Stejně si ho člověk krátce po napsání chce taky vyzkoušet, že jo...
) Třeba ty accessory v Ruby a v Lispu prostě jinak zjistit nejdou, leda, že by se udělala ad-hoc omezená statická analýza omezená pouze na standardní jazyk. Což by ve větším kódu asi dlouho nevydrželo.
(Forth vynechám, ten je na tom teoreticky nejhůř, ale asi se neočekává, že by někdo do několikakilobajtového softwaru montoval Visual Studio
)
Slime to řeší úplně jednoduše s přímočaře. C-c C-k provede compile-file a load. Tím pádem se dostane kód do běžícího lispu a je přístupný pro swank (serverová část Slime). Completion je řešená na straně serveru, tedy v tom bežícím procesu. Slime klient v Emacsu tedy nepředstírá, že umí doplňovat symboly z aktuálního souboru - to umět samozřejmě nemůže.
Tahá si je ze spuštěného image.
Zákonitě se nenajde nikdo, komu by to vadilo, přestože jde o tentýž proces, jako v případě Vimu a Ruby.
Jediný rozdíl je v tom, že tady je ta kompilace explicitní.
Mimochodem, fuzzy code completion ve Slime je z pohledu lispera úplný mazlíček. Třeba negado expanduje na most-negative-double-float, wiof na with-open-file...prostě expanduje podle procenta fuzzy matche dost vychytaným způsobem...
To by možná ocenili i javisti a C#aři, kdyby jim oumeme + TAB samo vyhodilo OutOfMemoryException (OutOfMemoryError) a nemuseli se se vším tak psát, zvlášť, když z toho dělají proměnnou a musejí to psát dvakrát.
Docela by mě zajímalo, co na tomhle poli šikovných fíčur vznikne v průběhu příštích dvaceti let a jak se s tím editory vypořídají.
if ($a == ($b ± autobus)) {
...
}
hmm, a to sa jeden čuduje, prečo im ten vývoj trvá tak dlho
On je trochu rozdíl mezi textovým editorem a interaktivním interpretrem. VIM se pokud vím interaktivním interpretrem nenazývá
Spousta editorů ten interpret obsahuje nebo nějaký umožňuje používat. Nehledě na to, že já zásadně nepoužívám textové editory. Používám výhradně interaktivní interpret Emacs Lispu, který se (jen) jako textový editor defaultně tváří.
Na běžné věci používam Kate a když programuju v Pythonu tak Eric3 (který autocompletion v Pythonu dělá a to aniž by vykonával kód
). Sice v něm to doplňování kódu asi nebude tak "dokonalé" jako v editorech který ten kód vykonávají, ale mně to stačí a nemusim se bát, že mi textový editor napáchá škody v systému
No a jako interaktivní interpretr nejčastěji používám výborný IPython, ten nemá konkurenci
A v konzoli třeba na editaci konfiguráků mi bohatě stačí nano
Možná by to stálo za nějaký Slime-reklamní blogpost. Nebo rovnou video.
http://common-lisp.net/movies/slime.mov
No jo, ale já stejně přemýšlím, že v téhle zemi se tvoří příliš málo screencastů...
Taková skvélá forma sdělování informací a ono kde nic, tu nic.
(((vím, ((jsem ignorant) a tohle) je) poněkud laciný) (humor))
Neupírám Vimu jednu přednost: Mnoho textových editorů obsahuje závažný bug, který náhodně poškozuje editovaný text a vkládá do něj náhodný šum, například :wq!, ZZ nebo qq. Ani Emacs se tomu nevyhnul. Vim je zato z nějakého důvodu imunní.
Mimochodem, převeďte si "vi vi vi" z římských číslic na arabské a pochopíte postoj Církve Emacsu k tomuto tématu...
Statickým parsingem zase všechny metody člověk nezjistí, nebo aspoň ne obecně. Můžu mít ošetřený attr_reader, attr_writer a attr_accessor, ale podobné "metaprogramovací metody" si člověk může nadefinovat sám a pak je editor bez pomoci v pytli.
Vítejte do světa dynamických jazyků...
Jó, kdo přičichne k lispu, uvědomí si, že i pouhá kompilace může mít side-effecty, protože při ní dochází třeba ke spouštění makrofunkcí (ty side-effecty ovšem mohou být záměr).
)
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.