Portál AbcLinuxu, 2. května 2025 17:23
5.6.2006 22:39
JiK | skóre: 13
| blog: Jirkoviny
| Virginia
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ě.
6.6.2006 14:35
Josef Kufner | skóre: 70
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ý.
5.6.2006 23:12
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
5.6.2006 23:15
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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
6.6.2006 14:53
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
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áří.
6.6.2006 15:39
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
6.6.2006 15:48
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
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
6.6.2006 15:49
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
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.
7.6.2006 14:30
Mikos | skóre: 34
| blog: Jaderný blog
| Praha
(((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).
5.6.2006 23:16
Josef Kufner | skóre: 70
6.6.2006 12:34
Josef Kufner | skóre: 70
)
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.