Dowiązania magiczne¶

Istnieje specjalna klasa obiektów dowiązaniopodobnych™ zwanych „dowiązaniami magicznymi”, które występują w określonych pseudosystemach plików, takich jak proc(5) (np. /proc/pid/exe i /proc/pid/fd/*). W przeciwieństwie do standardowych dowiązań symbolicznych, dowiązania magiczne nie są rozwiązywane za pomocą podążania za ścieżką, lecz są bezpośrednimi odniesieniami do własnych reprezentacji jądra wobec uchwytów plików. Jako takie, dowiązania magiczne umożliwiają użytkownikom dostęp do plików, do których nie mogą odnosić się zwykłe ścieżki (np. do odlinkowanych plików, do których wciąż odnosi się działający program).

Dowiązania magiczne mogą pomijać standardowe ograniczenia wynikające z przestrzeni nazw montowań (mount_namespaces(7)), dlatego były już wektorem ataków stosowanym przez różne exploity.

Własności, uprawnienia i znaczniki czasowe dowiązań symbolicznych¶

Właściciela i grupę istniejącego dowiązania symbolicznego można zmienić za pomocą lchown(2). Własność dowiązania symbolicznego ma znaczenie, gdy dowiązanie jest usuwane lub zmieniane w katalogu, który ma ustawiony bit lepkości (zob. inode(7)) oraz gdy ustawiona jest kontrolka systemowa fs.protected_symlinks (zob. proc(5)).

Znaczniki czasowe ostatniego dostępu i ostatniej modyfikacji dowiązania symbolicznego można zmienić za pomocą utimensat(2) lub lutimes(3).

W Linuksie, uprawnienia standardowego dowiązania symbolicznego nie są używane przy żadnych operacjach; uprawnienia są ustawione zawsze na 0777 (odczyt, zapis i wykonanie dla wszystkich kategorii użytkowników) i nie mogą być zmieniane.

Dowiązania magiczne nie przestrzegają jednak tej reguły. Mogą mieć tryb inny niż 0777, choć nie jest to obecnie używane przy żadnych sprawdzeniach uprawnień.

Pozyskiwanie deskryptora pliku odnoszącego się do dowiązania symbolicznego¶

Łącząc w open(2) znaczniki O_PATH i O_NOFOLLOW można uzyskać deskryptor pliku, które można przekazać jako argument dirfd wywołaniom systemowym, takim jak: fstatat(2), fchownat(2), fchmodat(2), linkat(2) i readlinkat(2), aby działać na samym dowiązaniu symbolicznym (a nie na pliku, do którego się ono odnosi).

Domyślnie (tj. bez znacznika AT_SYMLINK_FOLLOW) jeśli do dowiązania symbolicznego zastosuje się name_to_handle_at(2), to zwróci ono uchwyt do dowiązania symbolicznego (a nie pliku, do którego się ono odnosi). Można następnie uzyskać deskryptor pliku samego dowiązania symbolicznego (a nie pliku, do którego się ono odnosi), podając znacznik O_PATH w kolejnym wywołaniu do open_by_handle_at(2). Ten deskryptor pliku można użyć w opisanych wcześniej wywołaniach systemowych, aby działać na samym dowiązaniu symbolicznym.

Obsługa dowiązań symbolicznych przez polecenia i wywołania systemowe¶

Działania wobec dowiązań symbolicznych są dokonywane albo na samym dowiązaniu, albo na obiekcie, do którego odnosi się dowiązanie. W tym drugim przypadku mówi się, że aplikacja lub wywołanie systemowe podąża za dowiązaniem. Dowiązania symboliczne może odnosić się do kolejnych dowiązań symbolicznych; wówczas dowiązania są rozwiązywane do momentu: odnalezienia obiektu niebędącego dowiązaniem symbolicznym, odnalezienia dowiązania symbolicznego odnoszącego się do nieistniejącego pliku albo wykrycia pętli (pętle są wykrywane poprzez nałożenie górnego limitu na kolejne podążanie za dowiązaniami i wystąpieniu błędu po jego przekroczeniu).

Konieczne jest omówienie trzech odrębnych przypadków. Oto one:

•

Dowiązania symboliczne będące argumentami do wywołań systemowych.

•

Dowiązania symboliczne będące argumentami wiersza poleceń do narzędzi, które nie przechodzą przez drzewo plików.

•

Dowiązania symboliczne, na które napotkają narzędzia przechodzące przez drzewo plików (albo podane w wierszu poleceń, albo napotkane przy przechodzeniu przez drzewo plików).

Przed opisem traktowania dowiązań symbolicznych przez polecenia i wywołania systemowe, konieczne będzie zdefiniowanie pewnych pojęć. Zakładając, że ścieżka ma postać a/b/c, część poprzedzająca ostatni ukośnik (tj. a/b) jest nazywana składową dirname (katalogową), a część po ostatnim ukośniku (tj. c) jest nazywana składową basename (podstawową).

Traktowanie dowiązań symbolicznych w wywołaniach systemowych¶

Pierwszy przypadek dotyczy dowiązań symbolicznych, użytych jako argumenty z nazwą pliku w wywołaniach systemowych.

Dowiązania symboliczne w ścieżce przekazywanej do wywołania systemowego są traktowane następująco:

(1)

W składowej dirname (katalogowej) ścieżki, podąża się za dowiązaniami symbolicznymi zawsze, w niemal każdym wywołaniu systemowym (jest to prawdziwe również dla poleceń). Jedynym wyjątkiem jest openat2(2), które udostępnia znaczniki, mogące być użyte do wyłączenia podążania za dowiązaniami symbolicznymi w składowej dirname (katalogowej).

(2)

Poza wyjątkami opisanymi poniżej, wszystkie wywołania systemowe podążają za dowiązaniami symbolicznymi w składowej basename (podstawowej) ścieżki. Przykładowo, jeśli istniałoby dowiązanie symboliczne slink wskazujące na plik o nazwie afile, to wywołanie systemowe open("slink" ...) zwróciłoby deskryptor pliku odnoszący się do pliku afile.

Istnieją wywołania systemowe, które nie podążają za dowiązaniami w składowej basename (podstawowej) ścieżki, lecz działają na samym dowiązaniu symbolicznym. Są to: lchown(2), lgetxattr(2), llistxattr(2), lremovexattr(2), lsetxattr(2), lstat(2), readlink(2), rename(2), rmdir(2) oraz unlink(2).

Pewne inne wywołania systemowe opcjonalnie podążają za dowiązaniami symbolicznymi w składowej basename (podstawowej) ścieżki. Są to: faccessat(2), fchownat(2), fstatat(2), linkat(2), name_to_handle_at(2), open(2), openat(2), open_by_handle_at(2) i utimensat(2); więcej szczegółów w innych podręcznikach systemowych. Jako że remove(3) jest aliasem unlink(2), ta funkcja biblioteczna nie podąża za dowiązaniami symbolicznymi. Gdy do dowiązania symbolicznego zastosuje się rmdir(2), to wywołanie zawiedzie z błędem ENOTDIR.

link(2) zasługuje na odrębny opis. POSIX.1-2001 określa, że link(2) powinno rozwiązywać oldpath, jeśli jest to dowiązanie symboliczne. Linux tego jednak nie robi (domyślnie Solaris zachowuje się tak samo, ale zachowanie z POSIX.1-2001 można uzyskać odpowiednimi opcjami kompilatora). W POSIX.1-2008 zmieniono normę, zezwalając w implementacji na oba zachowania.

Polecenia nieprzechodzące przez drzewo plików¶

Drugim przypadkiem są dowiązania symboliczne, podawane jako argumenty nazwy pliku w wierszu polecenia poleceniom, które nie przechodzą przez drzewo plików.

Z wyjątkami opisanymi poniżej, polecenia podążają za dowiązaniami symbolicznymi, podanymi jako argumenty w wierszu poleceń. Na przykład, jeśli istniałoby dowiązanie symboliczne slink wskazujące na plik o nazwie afile, polecenie cat slink wyświetliłoby zawartość pliku afile.

Jest istotne, aby uświadomić sobie, że reguła ta obejmuje polecenia, które mogą opcjonalnie przechodzić przez drzewo plików np. reguła ta dotyczy polecenia chown file, natomiast nie dotyczy polecenia chown -R file, ponieważ przechodzi ono przez drzewo plików (to ostatnie stanowi trzeci przypadek, opisany w podrozdziale poniżej).

Jeśli wyraźnym zamiarem jest działanie polecenia na samym dowiązaniu symbolicznym, zamiast podążanie za nim — np. jeśli chce się zmienić za pomocą chown slink własność pliku slink, niezależnie od tego, czy jest to dowiązanie symboliczne, czy też nie — powinno się zastosować opcję -h. W powyższym przykładzie chown root slink zmieniłoby własność pliku, do którego odnosi się slink, natomiast chown -h root slink zmieniłoby własność samego slink.

Od tej reguły istnieją pewne wyjątki:

•

Polecenia mv(1) i rm(1) nie podążają za dowiązaniami symbolicznymi podanymi jako argumenty, lecz próbują je, odpowiednio, przemianować i usunąć (proszę zauważyć, że jeśli dowiązanie symboliczne odnosi się do pliku przez ścieżkę względną, przeniesienie go do innego katalogu może równie dobrze spowodować, że przestanie ono działać, ponieważ ścieżka może nie być już poprawna).

•

Polecenie ls(1) również jest wyjątkiem od tej reguły. Ze względu na kompatybilność z dawnymi systemami (gdy ls(1) nie przechodzi przez drzewo — tj. nie podano opcji -R), polecenie ls(1) podąża za dowiązaniami symbolicznymi podanymi jako argumenty, jeśli podano opcje -H lub -L, albo gdy nie podano opcji -F, -d lub -l (polecenie ls(1) jest jedynym poleceniem, gdzie opcje -H i -L wpływają na jego zachowanie, nawet gdy nie jest dokonywane przejście przez drzewo plików).

•

Polecenie file(1) również jest wyjątkiem od tej reguły. Polecenie file(1) nie podąża za dowiązaniami symbolicznymi, podanymi jako argument. Polecenie file(1) podąża za dowiązaniami symbolicznymi podanymi jako argument, gdy podano opcję -L.

Polecenia przechodzące przez drzewo plików¶

Polecenia, które albo opcjonalnie, albo zawsze przechodzą przez drzewo plików: chgrp(1), chmod(1), chown(1), cp(1), du(1), find(1), ls(1), pax(1), rm(1) i tar(1).

Jest istotne aby uświadomić sobie, że poniższe reguły stosują się zarówno do dowiązań symbolicznych napotkanych przy przechodzeniu przez drzewo plików, jak i do dowiązań symbolicznych podanych jako argumenty wiersza poleceń.

Pierwsza reguła stosuje się do dowiązań symbolicznych, odnoszących się do plików innych niż katalogi. Operacje, które dotyczą dowiązań symbolicznych, są wykonywane na samych dowiązaniach symbolicznych, lecz poza tym, dowiązania są ignorowane.

Polecenie rm -r slink directory usunie slink, oraz wszelkie dowiązania symboliczne napotkane przy przechodzeniu drzewa katalogu directory, ponieważ dowiązania symboliczne mogą być usuwane. W żadnym przypadku rm(1) nie będzie dotyczyć pliku wskazywanego przez slink.

Druga reguła dotyczy dowiązań symbolicznych, odnoszących się do katalogów. Domyślnie, nigdy nie podąża się za dowiązaniami symbolicznymi wskazującymi na katalogi. Często nazywane jest to przejściem „fizycznym”, w odróżnieniu od przejścia „logicznego” (gdy podąża się za dowiązaniami symbolicznymi odnoszącymi się do katalogów).

Istnieją pewne konwencje, które są (a przynajmniej powinny być) przestrzegane, przez programy dokonujące przejścia przez drzewo plików, tak ściśle, jak to możliwe:

•

Można sprawić, aby polecenie podążało za wszelkimi dowiązaniami symbolicznymi podanymi w wierszu poleceń, niezależnie od typu pliku, do jakiego się odnoszą, podając opcję -H (od ang „half-logical” — „półlogiczny”). Opcja ta ma na celu upodobnienie przestrzeni nazw wiersza poleceń do logicznej przestrzeni nazw (proszę zauważyć, że w przypadku poleceń, które nie zawsze przechodzą przez drzewo plików, opcja -H zostanie zignorowana, jeśli nie podano również -R).

Dla przykładu, polecenie chown -HR user slink przejdzie przez hierarchię plików zakorzenionych w pliku, na który wskazuje slink. Proszę zauważyć, że -H nie jest tym samym, co opisywana wcześniej opcja -h. Opcja -H powoduje, że dowiązania symboliczne podane w wierszu poleceń są rozwiązywane w celu zarówno przeprowadzenia akcji, jak i przejścia przez drzewo, i jest to to samo, co podanie przez użytkownika nazwy pliku, na którą wskazuje dowiązanie symboliczne.

•

Można spowodować, aby polecenie podążało za dowiązaniami symbolicznymi podanymi w wierszu poleceń, jak również wszelkimi dowiązaniami symbolicznymi napotkanymi przy przejściu przez drzewo plików, niezależnie od typu plików, na które wskazują, podając opcję -L („logiczny”). Opcja ta ma na celu upodobnienie całej przestrzeni nazw do logicznej przestrzeni nazw (proszę zauważyć, że w przypadku poleceń, które nie zawsze przechodzą przez drzewo plików, opcja -L zostanie zignorowana, jeśli nie podano również -R).

Dla przykładu, polecenie chown -LR user slink zmieni właściciela pliku, do którego odnosi się slink. Jeśli slink wskazuje na katalog, chown przejdzie przez hierarchię plików zakorzenionych w katalogu, na który on wskazuje. Dodatkowo, wszelkie dowiązania symboliczne napotkane w dowolnym drzewie plików, przez który przejdzie chown, zostaną potraktowane w ten sam sposób co slink.

•

Można sprawić, aby polecenie zachowało się w sposób domyślny podając opcję -P (od ang. „physical” — „fizyczny”). Opcja ta ma na celu upodobnienie całej przestrzeni nazw do fizycznej przestrzeni nazw.

W przypadku poleceń, które domyślnie nie przechodzą przez drzewo plików, opcje -H, -L i -P są ignorowane, jeśli nie poda się równocześnie opcji -R. Dodatkowo, można podać opcje -H, -L i -P więcej niż raz; podana jako ostatnia określa zachowanie polecenia. Ma to na celu umożliwienie utworzenia aliasów poleceń, korzystających z tych opcji, a jednocześnie umożliwienie późniejszego przesłonienie zachowania podanego w aliasie, z wiersza poleceń.

Polecenia ls(1) i rm(1) mają wyjątki do tych reguł:

•

Polecenie rm(1) działa na samym dowiązaniu symbolicznym, a nie na pliku, na który ono wskazuje, zatem nigdy nie podąża za dowiązaniem symbolicznym. Polecenie rm(1) nie obsługuje opcji -H, -L ani -P.

•

Aby zachować kompatybilność z dawnymi systemami, polecenie ls(1) działa nieco odmiennie. Jeśli nie poda się opcji -F, -d lub -l, ls(1) będzie podążało za dowiązaniami symbolicznymi podanymi w wierszu poleceń. Jeśli poda się opcję -L, ls(1) podąża za wszelkimi dowiązaniami symbolicznymi, niezależnie od ich typu i tego, czy zostały podane w wierszu poleceń, czy napotkane przy przejściu przez drzewo.