18.12.2006 09:47
CIJOML | skóre: 58
| Praha
Rozbalit Rozbalit vše Re: Jaderné noviny - 21. 11. 2006
Portál AbcLinuxu, 6. května 2025 07:40
Aktuální verze jádra: 2.6.19-rc6. Citáty týdne: Greg Kroah-Hartman, Linus Torvalds. Shrnutí API změn v 2.6.19. Správa klíčů v jádře.
Aktuální předverze je 2.6.19-rc6, vydaná 15. listopadu. Obsahuje slušnou řádku oprav, ale doufejme, že většina problémů už byla vyřešena (i když poslední verze seznamu regresí v 2.6.19 (21. listopadu) pořád čítá devět položek). Podrobnosti v dlouhém changelogu.
Od vydání -rc6 bylo do hlavního git repozitáře zařazeno téměř 90 oprav. Zatím se nikdo nevyjádřil k tomu, jestli je to dost na vydání -rc7.
Během posledního týdne nevyšla žádná -mm verze.
Aktuální stabilní 2.6 jádro je 2.6.18.3, vydané 18. listopadu. Také obsahuje dost oprav, z nichž alespoň jedna řeší bezpečnostní problém.
Adrian Bunk vydal 2.6.16.32 a k dispozici je i 2.6.16.33-rc1.
Willy Tarreau vydal 2.4.33.4 se dvěma bezpečnostními patchi a množstvím dalších oprav. 2.4.34-pre6 už je také venku. Přidává jen několik patchů.
Nevím o tom, že by se o ovladačovém modelu mluvilo jako o "kompletním vzoru designu". Říkaly se o něm však hodně ošklivé věci.
Nenachytejte se na "efekt druhého systému". Klasický důvod pro pokažení druhého systému je zaměření na věci, kvůli kterým si lidi stěžují, místo na ty, které fungují dobře (protože to, co funguje správně, není tolik na očích).
Jaderný cyklus verze 2.6.19 přinesl obvyklou várku změn, které pocítí vývojáři jádra. Následuje shrnutí nejvýraznější úprav API v 2.6.19.
Nová funkce pro alokaci kopie bloku paměti:
void *kmemdup(const void *src, size_t len, gfp_t gfp);
Množství sekvencí alokuj-pak-kopíruj bylo aktualizováno, aby používaly právě kmemdup().
Souborové systémy, především pak vzdálené souborové systémy, mohou pro umožnění přístupu vyžadovat nějakou autentizaci nebo klíč; jaderné rozhraní pro správu klíčů poskytuje háčky [hooks] pro ukládání a správu tohoto druhu informací. Háčky jsou dvojího druhu: jeden využívá jádro k nalezení klíčů pro subsystémy, které je vyžadují, druhý využívají uživatelské programy pro správu klíčů. Účelem je poskytnout rychlý mechanismus, aby mohlo jádro přistupovat ke klíčům, které potřebuje, zatímco operace přidávání, úpravy a mazání jsou odsunuty do uživatelského prostoru.
Používá se termín 'klíč', ale nemusí se jednat o klíče v tradičním, šifrovacím smyslu. Jako klíč může být uložen jakýkoliv druh autentizační nebo přístupové informace; v podstatě se jedná o nečitelný kus dat, který je interpretován jaderným subsystémem, jehož se týká. Ačkoliv je API zaměřeno na souborové systémy, může ho využívat kterýkoliv jaderný subsystém, který vyžaduje tento typ informací.
Klíče jsou uloženy v příznačně pojmenované struct key, která má následující pole:
Typy klíčů umožňují souborovým systémům konfigurovat svou vlastní sadu operací s klíči. Typ klíče může určit následující operace:
Jsou definovány dva standardní typy klíčů: key_type_user a key_type_keyring. Nové typy klíčů lze u souborových systémů registrovat pomocí:
int register_key_type(struct key_type *type);
Když jádro potřebuje najít klíč, zavolá:
struct key *request_key(const struct key_type *type,
const char *description,
const char *callout_string);
Předá type a description a funkce match z struct key_type je použita k nalezení odpovídajícího klíče. Není-li nalezen žádný a callout_string není NULL, spustí jádro /sbin/request-key, který se pokusí potřebný klíč získat z uživatelského prostředí.
K poli payload lze přistupovat po nalezení klíče, ale je-li komplexnější než obyčejné celé číslo, musí být postaráno o zabránění současnému čtení a zápisům. Ve struktuře klíčů je podpora semaforového zamykání a RCU; ty je potřeba vždy použít - kromě situace, kdy klíč nemá žádné metody pro úpravu. Jakmile souborový systém s klíčem skončí, měl by být uvolněn pomocí:
void key_put(struct key *key);
Kroužky klíčů [keyrings] jsou, jak název napovídá, skupiny souvisejících klíčů a pro manipulaci s nimi jsou připravena různá volání. Každý proces je přiřazen ke třem specifickým kroužkům klíčů: kroužek specifický pro vlákno, kroužek specifický pro proces a kroužek specifický pro sezení. To jsou kroužky prohledávané při spuštění request_key.
Práva klíčů jsou uložena v bitovém poli, podobně jako práva linuxového souboru, ale daleko podrobněji. Každý klíč má id uživatele a skupiny a masku práv pro každého ze čtyř potenciálních zájemců: vlastník, uživatel, skupina a ostatní. Maska se skládá ze šesti bitů:
Uživatelské API sestává ze tří hlavních systémových volání:
key_serial_t add_key(const char *type, const char *desc,
const void *payload, size_t plen,
key_serial_t keyring);
key_serial_t request_key(const char *type, const char *description,
const char *callout_info,
key_serial_t dest_keyring);
key_serial_t keyctl(int cmd, key_serial_t id, int create);
add_key() přidává klíč na určený kroužek. request_key(), podobně jako jeho jaderný protějšek, vyhledává klíč na základě typu a popisu, případně volá uživatelský prostor, není-li callout_info NULL. Také může klíč připojit k určenému kroužku, je-li nalezen. keyctl() je rozhraní podobné ioctl, které zajišťuje správu klíčů. <linux/keyctl.h> obsahuje 17 samostatných příkazů pro aktualizaci, změnu práv, vyhledávání, linkování, čtení a podobně.
Utilita /bin/keyctl, která je součástí balíku keyutils, nabízí jednoduché rozhraní pro uživatelská systémová volání pro zajištění práce s klíči z uživatelského prostoru. Záznamy /proc/keys a /proc/key-users v procfs umožňují uživateli prohlížet klíče a uživatele klíčů, které jádro právě spravuje.
Jediný souborový systém v aktuálním jádře 2.6, který API pro správu klíčů využívá, je eCryptfs. Místo vytváření vlastního typu používá uživatelský typ klíče a přímo nepodporuje zpětná volání do uživatelského prostoru. Místo toho používá příkaz mount.ecryptfs, který se uživatele zeptá na heslo, jež je pak uloženo jako klíč.
Podle prezentace Davea Howellse na 2006 Ottawa Linux Symposium (zde) plánuje do budoucna využití API několik dalších souborových systémů (např. CIFS, NFSv4 a AFS). Více informací a podrobná dokumentace v Documentation/keys.txt a Documentation/keys-request-key.txt.
Celkově to vypadá jako užitečné rozhraní pro jaderné subsystémy, které potřebují klíče. V souladu s tradicí je většina částí týkajících se nastavení a správy odsunuta do uživatelského prostoru. Nabízí všechny možnosti, které by od toho člověk očekával a můžeme jen doufat, že ho v budoucnu začne využívat více subsystémů.
Vizte článek .V značce <a href="..."></a> je URL, ale chybí text.
Ne, ale ted o neco vazneji. Je mi uplne fuk, zes nejspis vystudoval nejakou IT skolu, ale umet cesky je zaklad. Vyraz "klicove prstence" je proti duchu ceskeho jazyka a pokud se takovej paskvil nekde uci, asi bych uvazoval o zahozeni diplomu... 
Na druhou stranu je jasne, ze jsi opet jen provokoval a ja a mnoho ostatnich se opet nechalo dozrat a vyprovokovat. Gratuluji ti uprimne k tomuto veleuspechu.
18.12.2006 16:16
David Ježek | skóre: 83
| blog: Mostly_IMDB
18.12.2006 17:55
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
18.12.2006 19:35
David Ježek | skóre: 83
| blog: Mostly_IMDB
18.12.2006 20:35
JaMa | skóre: 1
| blog: jama
18.12.2006 21:31
David Watzke | skóre: 74
| blog: Blog...
| Praha
18.12.2006 17:52
Nenachytejte se na "efekt druhého systému". Klasický důvod pro pokažení druhého systému je zaměření na věci, kvůli kterým si lidi stěžují, místo na ty, které fungují dobře (protože to, co funguje správně, není tolik na očích).
Tsche, no to je teda překlad ! Šmarjá, čtete to vůbec než to začnete trapně překládat ? Linus mluví o tom že lidi mají tendenci nadávat že je něco špatně jen proto že je to "jinak" než dotyčný zvyklej, je to "syndrom jiného způsobu". A "getting the second system wrong" NENÍ "pokažení druhého systému" ale špatné pochopení druhého způsobu.
P.S. Captcha jako aktuální rok, to je teda gól !
[Behold, AstorLights had spoken !]
A "getting the second system wrong" NENÍ "pokažení druhého systému" ale špatné pochopení druhého způsobu.Nesouhlasím. Přečti si znovu kontext. P.S.:
[Behold, AstorLights had spoken !]Past perfect?
"Pokažení druhého systému" to je překlad, tsche, za á to přímo bolí v ušíchTo je pravda. "Pokažení" není moc hezké slovo.
za bé je to kolosální nesmysl, přemejšlej, JAK by asi mohli ten systém POKAZIT, he ? Co by mohli pokazit, GIT ? Jak jako ?Mluví se o úpravách gitu. Linus odpovídá (člověku, který zmiňuje Hg Mercurial) na volání po změně význam příkazu
git pull. Takže ano, pokazit by to mohlo git.
Dovol, abych ti citoval Wikipedii, na kterou jsem předtím jen odkazoval:
In computing, the second-system effect or sometimes the second-system syndrome is the tendency to design the successor to a relatively small, elegant, and successful system as an elephantine, feature-laden monstrosity.
Tj. Linusovi jde o to, aby další verze gitu neutrpěly kvůli tomuto efektu druhého systému. Nejedná se o žádné "nepochopení druhého způsobu".
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.