symlink(7) Miscellaneous Information Manual symlink(7) NAZWA symlink - obsluga dowiazan symbolicznych OPIS Dowiazania symboliczne sa plikami, ktore dzialaja jak wskazniki do innych plikow. Aby zrozumiec ich dzialanie, konieczne jest wczesniejsze poznanie mechanizmu dzialania dowiazan zwyklych. Dowiazanie zwykle do pliku jest nierozroznialne od pierwotnego pliku, poniewaz jest odniesieniem do samego obiektu, do ktorego odnosi sie pierwotna nazwa pliku (precyzyjniej: kazde z dowiazan zwyklych do pliku odnosi sie do tego samego numeru i-wezla: gdzie numer i-wezla jest numerem indeksu w tablicy i-wezlow, zawierajacej metadane o wszystkich plikach w systemie plikow. Zob. stat(2)). Zmiany w pliku sa niezalezne od nazwy, jaka odnosi sie do pliku. Dowiazania zwykle nie odnosza sie do katalogow (aby uniemozliwic wystapienie petli w drzewie systemu plikow, ktore zmylilyby wiele programow) i nie moga odnosic sie do plikow w innych systemach plikow (poniewaz numery i-wezlow nie sa unikalne pomiedzy systemami plikow). Dowiazanie symboliczne jest specjalnym typem pliku, ktorego zawartosc jest lancuchem, bedacym sciezka innego pliku -- pliku na ktory wskazuje dowiazanie (zawartosc dowiazania symbolicznego mozna odczytac za pomoca readlink(2)). Innymi slowy, dowiazanie symboliczne jest wskaznikiem do innej nazwy, a nie do samego obiektu. Z tego powodu, dowiazania symboliczne moga odnosic sie do katalogow i moga przekraczac granice systemu plikow. Nie ma wymagania aby sciezka, do ktorej odnosi sie dowiazanie symboliczne, musiala istniec. Dowiazanie symboliczne odnoszace sie do nieistniejacej sciezki jest nazywane dowiazaniem wiszacym. Dowiazanie symboliczne i obiekt, do ktorego sie odnosi, istnieja jednoczesnie w przestrzeni nazw systemu plikow, zatem moze dojsc do problemow w rozroznieniu samego dowiazania i obiektu na ktory ono wskazuje. W dawnych systemach, polecenia i wywolania systemowe zaadoptowaly swoje wlasne, dosc przypadkowe konwencje, dotyczace podazania za dowiazaniami. Tutaj opisano nieco bardziej spojne podejscie, opisujace sposob implementacji w systemie Linux i innych. Jest wazne, aby lokalne aplikacje w systemie rowniez przestrzegaly tych regul tak, aby interfejs uzytkownika byl jak najbardziej spojny. Dowiazania magiczne Istnieje specjalna klasa obiektow dowiazaniopodobnychtm zwanych ,,dowiazaniami magicznymi", ktore wystepuja w okreslonych pseudosystemach plikow, takich jak proc(5) (np. /proc/pid/exe i /proc/pid/fd/*). W przeciwienstwie do standardowych dowiazan symbolicznych, dowiazania magiczne nie sa rozwiazywane za pomoca podazania za sciezka, lecz sa bezposrednimi odniesieniami do wlasnych reprezentacji jadra wobec uchwytow plikow. Jako takie, dowiazania magiczne umozliwiaja uzytkownikom dostep do plikow, do ktorych nie moga odnosic sie zwykle sciezki (np. do odlinkowanych plikow, do ktorych wciaz odnosi sie dzialajacy program). Dowiazania magiczne moga pomijac standardowe ograniczenia wynikajace z przestrzeni nazw montowan (mount_namespaces(7)), dlatego byly juz wektorem atakow stosowanym przez rozne exploity. Wlasnosci, uprawnienia i znaczniki czasowe dowiazan symbolicznych Wlasciciela i grupe istniejacego dowiazania symbolicznego mozna zmienic za pomoca lchown(2). Wlasnosc dowiazania symbolicznego ma znaczenie, gdy dowiazanie jest usuwane lub zmieniane w katalogu, ktory ma ustawiony bit lepkosci (zob. inode(7)) oraz gdy ustawiona jest kontrolka systemowa fs.protected_symlinks (zob. proc(5)). Znaczniki czasowe ostatniego dostepu i ostatniej modyfikacji dowiazania symbolicznego mozna zmienic za pomoca utimensat(2) lub lutimes(3). W Linuksie, uprawnienia standardowego dowiazania symbolicznego nie sa uzywane przy zadnych operacjach; uprawnienia sa ustawione zawsze na 0777 (odczyt, zapis i wykonanie dla wszystkich kategorii uzytkownikow) i nie moga byc zmieniane. Dowiazania magiczne nie przestrzegaja jednak tej reguly. Moga miec tryb inny niz 0777, choc nie jest to obecnie uzywane przy zadnych sprawdzeniach uprawnien. Pozyskiwanie deskryptora pliku odnoszacego sie do dowiazania symbolicznego Laczac w open(2) znaczniki O_PATH i O_NOFOLLOW mozna uzyskac deskryptor pliku, ktore mozna przekazac jako argument dirfd wywolaniom systemowym, takim jak: fstatat(2), fchownat(2), fchmodat(2), linkat(2) i readlinkat(2), aby dzialac na samym dowiazaniu symbolicznym (a nie na pliku, do ktorego sie ono odnosi). Domyslnie (tj. bez znacznika AT_SYMLINK_FOLLOW) jesli do dowiazania symbolicznego zastosuje sie name_to_handle_at(2), to zwroci ono uchwyt do dowiazania symbolicznego (a nie pliku, do ktorego sie ono odnosi). Mozna nastepnie uzyskac deskryptor pliku samego dowiazania symbolicznego (a nie pliku, do ktorego sie ono odnosi), podajac znacznik O_PATH w kolejnym wywolaniu do open_by_handle_at(2). Ten deskryptor pliku mozna uzyc w opisanych wczesniej wywolaniach systemowych, aby dzialac na samym dowiazaniu symbolicznym. Obsluga dowiazan symbolicznych przez polecenia i wywolania systemowe Dzialania wobec dowiazan symbolicznych sa dokonywane albo na samym dowiazaniu, albo na obiekcie, do ktorego odnosi sie dowiazanie. W tym drugim przypadku mowi sie, ze aplikacja lub wywolanie systemowe podaza za dowiazaniem. Dowiazania symboliczne moze odnosic sie do kolejnych dowiazan symbolicznych; wowczas dowiazania sa rozwiazywane do momentu: odnalezienia obiektu niebedacego dowiazaniem symbolicznym, odnalezienia dowiazania symbolicznego odnoszacego sie do nieistniejacego pliku albo wykrycia petli (petle sa wykrywane poprzez nalozenie gornego limitu na kolejne podazanie za dowiazaniami i wystapieniu bledu po jego przekroczeniu). Konieczne jest omowienie trzech odrebnych przypadkow. Oto one: o Dowiazania symboliczne bedace argumentami do wywolan systemowych. o Dowiazania symboliczne bedace argumentami wiersza polecen do narzedzi, ktore nie przechodza przez drzewo plikow. o Dowiazania symboliczne, na ktore napotkaja narzedzia przechodzace przez drzewo plikow (albo podane w wierszu polecen, albo napotkane przy przechodzeniu przez drzewo plikow). Przed opisem traktowania dowiazan symbolicznych przez polecenia i wywolania systemowe, konieczne bedzie zdefiniowanie pewnych pojec. Zakladajac, ze sciezka ma postac a/b/c, czesc poprzedzajaca ostatni ukosnik (tj. a/b) jest nazywana skladowa dirname (katalogowa), a czesc po ostatnim ukosniku (tj. c) jest nazywana skladowa basename (podstawowa). Traktowanie dowiazan symbolicznych w wywolaniach systemowych Pierwszy przypadek dotyczy dowiazan symbolicznych, uzytych jako argumenty z nazwa pliku w wywolaniach systemowych. Dowiazania symboliczne w sciezce przekazywanej do wywolania systemowego sa traktowane nastepujaco: (1) W skladowej dirname (katalogowej) sciezki, podaza sie za dowiazaniami symbolicznymi zawsze, w niemal kazdym wywolaniu systemowym (jest to prawdziwe rowniez dla polecen). Jedynym wyjatkiem jest openat2(2), ktore udostepnia znaczniki, mogace byc uzyte do wylaczenia podazania za dowiazaniami symbolicznymi w skladowej dirname (katalogowej). (2) Poza wyjatkami opisanymi ponizej, wszystkie wywolania systemowe podazaja za dowiazaniami symbolicznymi w skladowej basename (podstawowej) sciezki. Przykladowo, jesli istnialoby dowiazanie symboliczne slink wskazujace na plik o nazwie afile, to wywolanie systemowe open("slink" ...) zwrociloby deskryptor pliku odnoszacy sie do pliku afile. Istnieja wywolania systemowe, ktore nie podazaja za dowiazaniami w skladowej basename (podstawowej) sciezki, lecz dzialaja na samym dowiazaniu symbolicznym. Sa to: lchown(2), lgetxattr(2), llistxattr(2), lremovexattr(2), lsetxattr(2), lstat(2), readlink(2), rename(2), rmdir(2) oraz unlink(2). Pewne inne wywolania systemowe opcjonalnie podazaja za dowiazaniami symbolicznymi w skladowej basename (podstawowej) sciezki. Sa 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); wiecej szczegolow w innych podrecznikach systemowych. Jako ze remove(3) jest aliasem unlink(2), ta funkcja biblioteczna nie podaza za dowiazaniami symbolicznymi. Gdy do dowiazania symbolicznego zastosuje sie rmdir(2), to wywolanie zawiedzie z bledem ENOTDIR. link(2) zasluguje na odrebny opis. POSIX.1-2001 okresla, ze link(2) powinno rozwiazywac oldpath, jesli jest to dowiazanie symboliczne. Linux tego jednak nie robi (domyslnie Solaris zachowuje sie tak samo, ale zachowanie z POSIX.1-2001 mozna uzyskac odpowiednimi opcjami kompilatora). W POSIX.1-2008 zmieniono norme, zezwalajac w implementacji na oba zachowania. Polecenia nieprzechodzace przez drzewo plikow Drugim przypadkiem sa dowiazania symboliczne, podawane jako argumenty nazwy pliku w wierszu polecenia poleceniom, ktore nie przechodza przez drzewo plikow. Z wyjatkami opisanymi ponizej, polecenia podazaja za dowiazaniami symbolicznymi, podanymi jako argumenty w wierszu polecen. Na przyklad, jesli istnialoby dowiazanie symboliczne slink wskazujace na plik o nazwie afile, polecenie cat slink wyswietliloby zawartosc pliku afile. Jest istotne, aby uswiadomic sobie, ze regula ta obejmuje polecenia, ktore moga opcjonalnie przechodzic przez drzewo plikow np. regula ta dotyczy polecenia chown file, natomiast nie dotyczy polecenia chown -R file, poniewaz przechodzi ono przez drzewo plikow (to ostatnie stanowi trzeci przypadek, opisany w podrozdziale ponizej). Jesli wyraznym zamiarem jest dzialanie polecenia na samym dowiazaniu symbolicznym, zamiast podazanie za nim -- np. jesli chce sie zmienic za pomoca chown slink wlasnosc pliku slink, niezaleznie od tego, czy jest to dowiazanie symboliczne, czy tez nie -- powinno sie zastosowac opcje -h. W powyzszym przykladzie chown root slink zmieniloby wlasnosc pliku, do ktorego odnosi sie slink, natomiast chown -h root slink zmieniloby wlasnosc samego slink. Od tej reguly istnieja pewne wyjatki: o Polecenia mv(1) i rm(1) nie podazaja za dowiazaniami symbolicznymi podanymi jako argumenty, lecz probuja je, odpowiednio, przemianowac i usunac (prosze zauwazyc, ze jesli dowiazanie symboliczne odnosi sie do pliku przez sciezke wzgledna, przeniesienie go do innego katalogu moze rownie dobrze spowodowac, ze przestanie ono dzialac, poniewaz sciezka moze nie byc juz poprawna). o Polecenie ls(1) rowniez jest wyjatkiem od tej reguly. Ze wzgledu na kompatybilnosc z dawnymi systemami (gdy ls(1) nie przechodzi przez drzewo -- tj. nie podano opcji -R), polecenie ls(1) podaza za dowiazaniami symbolicznymi podanymi jako argumenty, jesli 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 wplywaja na jego zachowanie, nawet gdy nie jest dokonywane przejscie przez drzewo plikow). o Polecenie file(1) rowniez jest wyjatkiem od tej reguly. Polecenie file(1) nie podaza za dowiazaniami symbolicznymi, podanymi jako argument. Polecenie file(1) podaza za dowiazaniami symbolicznymi podanymi jako argument, gdy podano opcje -L. Polecenia przechodzace przez drzewo plikow Polecenia, ktore albo opcjonalnie, albo zawsze przechodza przez drzewo plikow: chgrp(1), chmod(1), chown(1), cp(1), du(1), find(1), ls(1), pax(1), rm(1) i tar(1). Jest istotne aby uswiadomic sobie, ze ponizsze reguly stosuja sie zarowno do dowiazan symbolicznych napotkanych przy przechodzeniu przez drzewo plikow, jak i do dowiazan symbolicznych podanych jako argumenty wiersza polecen. Pierwsza regula stosuje sie do dowiazan symbolicznych, odnoszacych sie do plikow innych niz katalogi. Operacje, ktore dotycza dowiazan symbolicznych, sa wykonywane na samych dowiazaniach symbolicznych, lecz poza tym, dowiazania sa ignorowane. Polecenie rm -r slink directory usunie slink, oraz wszelkie dowiazania symboliczne napotkane przy przechodzeniu drzewa katalogu directory, poniewaz dowiazania symboliczne moga byc usuwane. W zadnym przypadku rm(1) nie bedzie dotyczyc pliku wskazywanego przez slink. Druga regula dotyczy dowiazan symbolicznych, odnoszacych sie do katalogow. Domyslnie, nigdy nie podaza sie za dowiazaniami symbolicznymi wskazujacymi na katalogi. Czesto nazywane jest to przejsciem ,,fizycznym", w odroznieniu od przejscia ,,logicznego" (gdy podaza sie za dowiazaniami symbolicznymi odnoszacymi sie do katalogow). Istnieja pewne konwencje, ktore sa (a przynajmniej powinny byc) przestrzegane, przez programy dokonujace przejscia przez drzewo plikow, tak scisle, jak to mozliwe: o Mozna sprawic, aby polecenie podazalo za wszelkimi dowiazaniami symbolicznymi podanymi w wierszu polecen, niezaleznie od typu pliku, do jakiego sie odnosza, podajac opcje -H (od ang ,,half-logical" -- ,,pollogiczny"). Opcja ta ma na celu upodobnienie przestrzeni nazw wiersza polecen do logicznej przestrzeni nazw (prosze zauwazyc, ze w przypadku polecen, ktore nie zawsze przechodza przez drzewo plikow, opcja -H zostanie zignorowana, jesli nie podano rowniez -R). Dla przykladu, polecenie chown -HR user slink przejdzie przez hierarchie plikow zakorzenionych w pliku, na ktory wskazuje slink. Prosze zauwazyc, ze -H nie jest tym samym, co opisywana wczesniej opcja -h. Opcja -H powoduje, ze dowiazania symboliczne podane w wierszu polecen sa rozwiazywane w celu zarowno przeprowadzenia akcji, jak i przejscia przez drzewo, i jest to to samo, co podanie przez uzytkownika nazwy pliku, na ktora wskazuje dowiazanie symboliczne. o Mozna spowodowac, aby polecenie podazalo za dowiazaniami symbolicznymi podanymi w wierszu polecen, jak rowniez wszelkimi dowiazaniami symbolicznymi napotkanymi przy przejsciu przez drzewo plikow, niezaleznie od typu plikow, na ktore wskazuja, podajac opcje -L (,,logiczny"). Opcja ta ma na celu upodobnienie calej przestrzeni nazw do logicznej przestrzeni nazw (prosze zauwazyc, ze w przypadku polecen, ktore nie zawsze przechodza przez drzewo plikow, opcja -L zostanie zignorowana, jesli nie podano rowniez -R). Dla przykladu, polecenie chown -LR user slink zmieni wlasciciela pliku, do ktorego odnosi sie slink. Jesli slink wskazuje na katalog, chown przejdzie przez hierarchie plikow zakorzenionych w katalogu, na ktory on wskazuje. Dodatkowo, wszelkie dowiazania symboliczne napotkane w dowolnym drzewie plikow, przez ktory przejdzie chown, zostana potraktowane w ten sam sposob co slink. o Mozna sprawic, aby polecenie zachowalo sie w sposob domyslny podajac opcje -P (od ang. ,,physical" -- ,,fizyczny"). Opcja ta ma na celu upodobnienie calej przestrzeni nazw do fizycznej przestrzeni nazw. W przypadku polecen, ktore domyslnie nie przechodza przez drzewo plikow, opcje -H, -L i -P sa ignorowane, jesli nie poda sie rownoczesnie opcji -R. Dodatkowo, mozna podac opcje -H, -L i -P wiecej niz raz; podana jako ostatnia okresla zachowanie polecenia. Ma to na celu umozliwienie utworzenia aliasow polecen, korzystajacych z tych opcji, a jednoczesnie umozliwienie pozniejszego przeslonienie zachowania podanego w aliasie, z wiersza polecen. Polecenia ls(1) i rm(1) maja wyjatki do tych regul: o Polecenie rm(1) dziala na samym dowiazaniu symbolicznym, a nie na pliku, na ktory ono wskazuje, zatem nigdy nie podaza za dowiazaniem symbolicznym. Polecenie rm(1) nie obsluguje opcji -H, -L ani -P. o Aby zachowac kompatybilnosc z dawnymi systemami, polecenie ls(1) dziala nieco odmiennie. Jesli nie poda sie opcji -F, -d lub -l, ls(1) bedzie podazalo za dowiazaniami symbolicznymi podanymi w wierszu polecen. Jesli poda sie opcje -L, ls(1) podaza za wszelkimi dowiazaniami symbolicznymi, niezaleznie od ich typu i tego, czy zostaly podane w wierszu polecen, czy napotkane przy przejsciu przez drzewo. ZOBACZ TAKZE chgrp(1), chmod(1), find(1), ln(1), ls(1), mv(1), namei(1), rm(1), lchown(2), link(2), lstat(2), readlink(2), rename(2), symlink(2), unlink(2), utimensat(2), lutimes(3), path_resolution(7) TLUMACZENIE Tlumaczenie niniejszej strony podrecznika: Michal Kulach Niniejsze tlumaczenie jest wolna dokumentacja. Blizsze informacje o warunkach licencji mozna uzyskac zapoznajac sie z GNU General Public License w wersji 3 lub nowszej. Nie przyjmuje sie ZADNEJ ODPOWIEDZIALNOSCI. Bledy w tlumaczeniu strony podrecznika prosimy zglaszac na adres listy dyskusyjnej . Linux man-pages 6.15 17 maja 2025 r. symlink(7)