Proc se vubec s labelem v te aplikaci takhle pracuje ? Nejak me nenapadaji duvody proc bych mel brat label zarizeni a cpat jej nekam do execu ?
Dyt label slouzi snad jen k zobrazeni uzivateli, pokud se pouziva i k necemu jinemu tak je asi neco spatne ne ?
Co jsem se tak dival na kod toho .cpp kde tato chyba byla, tak me teda moc nenadchl, napr. reseni case sensitivity v switchi: https://cgit.kde.org/plasma-workspace.git/tree/soliduiserver/deviceserviceaction.cpp?id=f32002ce50edc3891f1fa41173132c820b917d57#n103
nebylo by pouziti QString.toLower() lepsi reseni ? nebo mi neco unika ? (nemam cas si projit cely projekt - jdu ted spat)
Tuším, že label sa používa ako adresár, kde sa disk pripojí. Takže nejaký mkdir /media/<user>/<label> a potom mount. (Teraz ma napadlo, že treba vyskúšať, čo sa stane ak label bude obsahovať lomku...)
Ale ako som písal vyššie, zostaviť si argumenty ručne a dať ich do execve-like funkcie je bezpečnejšie, tam sa shell neaplikuje.
A čo sa týka zdrojákov, to je normálka. Nad nejakým case sensitivity v switchi sa ani netreba pozastavovať.
No to je trochu blbost ne ? Co kdyz budu mit dva flashdisky se stejnym label ? :-D
Ja mel za to ze jako automaticky mountpoint se pouziva nejake UUID ... ano ted jsem to vyzkousel i u FAT se pouziva UUID, /run/media/user/4F67-E98B Takze stale nechapu proc se v tom kodu cpe label nekam do exec, zacina mi to pripadat jako spraseny navrh
No to je trochu blbost ne ? Co kdyz budu mit dva flashdisky se stejnym label ? :-D
Ne není to blbost. Uvažujete příliš jednoduše. Zkuste si to, nechci vám to prozrazovat, nebylo by to překvapení :D
Ja mel za to ze jako automaticky mountpoint se pouziva nejake UUID ... ano ted jsem to vyzkousel i u FAT se pouziva UUID, /run/media/user/4F67-E98B
UUID fs se používá, jen pokud nemá label ;-)
Takze stale nechapu proc se v tom kodu cpe label nekam do exec, zacina mi to pripadat jako spraseny navrh
Opět zkratkovité, jednoduché přemýšlení... Zadejte si do Dolphina nebo Run ap. např. ~ nebo $HOME ap. a třeba vám dojde proč to tak obecně je. U labelu FS jim to ušlo no.
Ne nedochazi mi to, ~ a $HOME jsou jen zjednoduseni aby prihlaseny user nemusel psat celou cestu k svemu home/stupidne ji hledat, nejak nevidim spojitost s label u FAT svazku, to ma byt jako dalsi zjednoduseni aby se BFU neztratil ? stale mi prijde pouziti nazvu svazku z nejakeho neznameho USB zarizeni nekde jinde nez jako text buttonu v nejakem GUI klikatku jako prasarna... kdyz tu mame pro potreby systemu UUID (ktery je sice take v FS, ale chranit jeden vstup je jednodusi nez dva)
> Ne není to blbost. Uvažujete příliš jednoduše. Zkuste si to, nechci vám to prozrazovat, nebylo by to překvapení :D
Nemam tu zadne dalsi zarizeni s FAT, a formatovat kvuli tomu nic nehodlam... typuji ze se pri konfliktu LABEL pouzije UUID nebo LABEL+'-1' etc. to ale stale nevysvetluje proc pouzivat LABEL misto UUID...
No jestli tedy oprava znamená, že se tady ten label escapuje a vznikne tedy na disku adresář s takhle veselým jmenem... tak jen čekám, kdo ho vezme a zase použije někde tak jak je, bez escapování.
SQL má bind proměnné, tohle by bash a system() taky potřebovaly... Za SQL injection si programátoři mohou sami, obrana je většinou jednoduchá (OK, ne vše je proměnná co se dá bindnout), ale speciální znaky v bashi jsou prostě peklo.