.\" -*- coding: UTF-8 -*-
.\" Copyright (c) 1992, 1993, 1994
.\"	The Regents of the University of California.  All rights reserved.
.\" and Copyright (C) 2008, 2014 Michael Kerrisk <mtk.manpages@gmail.com>
.\"
.\" SPDX-License-Identifier: BSD-3-Clause
.\"
.\"	@(#)symlink.7	8.3 (Berkeley) 3/31/94
.\" $FreeBSD: src/bin/ln/symlink.7,v 1.30 2005/02/13 22:25:09 ru Exp $
.\"
.\" 2008-06-11, mtk, Taken from FreeBSD 6.2 and heavily edited for
.\"     specific Linux details, improved readability, and man-pages style.
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH symlink 7 "2 maja 2024 r." "Linux man\-pages 6.9.1" 
.SH NAZWA
symlink \- obsługa dowiązań symbolicznych
.SH OPIS
Dowiązania symboliczne są plikami, które działają jak wskaźniki do innych
plików. Aby zrozumieć ich działanie, konieczne jest wcześniejsze poznanie
mechanizmu działania dowiązań zwykłych.
.P
Dowiązanie zwykłe do pliku jest nierozróżnialne od pierwotnego pliku,
ponieważ jest odniesieniem do samego obiektu, do którego odnosi się
pierwotna nazwa pliku (precyzyjniej: każde z dowiązań zwykłych do pliku
odnosi się do tego samego \fInumeru i\-węzła\fP: gdzie numer i\-węzła jest
numerem indeksu w tablicy i\-węzłów, zawierającej metadane o wszystkich
plikach w systemie plików. Zob. \fBstat\fP(2)). Zmiany w pliku są niezależne od
nazwy, jaka odnosi się do pliku. Dowiązania zwykłe nie odnoszą się do
katalogów (aby uniemożliwić wystąpienie pętli w drzewie systemu plików,
które zmyliłyby wiele programów) i nie mogą odnosić się do plików w innych
systemach plików (ponieważ numery i\-węzłów nie są unikalne pomiędzy
systemami plików).
.P
Dowiązanie symboliczne jest specjalnym typem pliku, którego zawartość jest
łańcuchem, będącym ścieżką innego pliku \[em] pliku na który wskazuje
dowiązanie (zawartość dowiązania symbolicznego można odczytać za pomocą
\fBreadlink\fP(2)). Innymi słowy, dowiązanie symboliczne jest wskaźnikiem do
innej nazwy, a nie do samego obiektu. Z tego powodu, dowiązania symboliczne
mogą odnosić się do katalogów i mogą przekraczać granice systemu plików.
.P
Nie ma wymagania aby ścieżka, do której odnosi się dowiązanie symboliczne,
musiała istnieć. Dowiązanie symboliczne odnoszące się do nieistniejącej
ścieżki jest nazywane \fIdowiązaniem wiszącym\fP.
.P
.\"
Dowiązanie symboliczne i obiekt, do którego się odnosi, istnieją
jednocześnie w przestrzeni nazw systemu plików, zatem może dojść do
problemów w rozróżnieniu samego dowiązania i obiektu na który ono
wskazuje. W dawnych systemach, polecenia i wywołania systemowe zaadoptowały
swoje własne, dość przypadkowe konwencje, dotyczące podążania za
dowiązaniami. Tutaj opisano nieco bardziej spójne podejście, opisujące
sposób implementacji w systemie Linux i innych. Jest ważne, aby lokalne
aplikacje w systemie również przestrzegały tych reguł tak, aby interfejs
użytkownika był jak najbardziej spójny.
.SS "Dowiązania magiczne"
Istnieje specjalna klasa obiektów dowiązaniopodobnych\[tm] zwanych
\[Bq]dowiązaniami magicznymi\[rq], które występują w określonych
pseudosystemach plików, takich jak \fBproc\fP(5) (np. \fI/proc/\fPpid\fI/exe\fP i
\fI/proc/\fPpid\fI/fd/\fP*). 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).
.P
.\"
Dowiązania magiczne mogą pomijać standardowe ograniczenia wynikające z
przestrzeni nazw montowań (\fBmount_namespaces\fP(7)), dlatego były już
wektorem ataków stosowanym przez różne exploity.
.SS "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ą \fBlchown\fP(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. \fBinode\fP(7)) oraz gdy ustawiona jest kontrolka systemowa
\fIfs.protected_symlinks\fP (zob. \fBproc\fP(5)).
.P
Znaczniki czasowe ostatniego dostępu i ostatniej modyfikacji dowiązania
symbolicznego można zmienić za pomocą \fButimensat\fP(2) lub \fBlutimes\fP(3).
.P
.\" Linux does not currently implement an lchmod(2).
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.
.P
.\" .P
.\" The
.\" 4.4BSD
.\" system differs from historical
.\" 4BSD
.\" systems in that the system call
.\" .BR chown (2)
.\" has been changed to follow symbolic links.
.\" The
.\" .BR lchown (2)
.\" system call was added later when the limitations of the new
.\" .BR chown (2)
.\" became apparent.
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ń.
.SS "Pozyskiwanie deskryptora pliku odnoszącego się do dowiązania symbolicznego"
Łącząc w \fBopen\fP(2) znaczniki \fBO_PATH\fP i \fBO_NOFOLLOW\fP można uzyskać
deskryptor pliku, które można przekazać jako argument \fIdirfd\fP wywołaniom
systemowym, takim jak: \fBfstatat\fP(2), \fBfchownat\fP(2), \fBfchmodat\fP(2),
\fBlinkat\fP(2) i \fBreadlinkat\fP(2), aby działać na samym dowiązaniu
symbolicznym (a nie na pliku, do którego się ono odnosi).
.P
Domyślnie (tj. bez znacznika \fBAT_SYMLINK_FOLLOW\fP) jeśli do dowiązania
symbolicznego zastosuje się \fBname_to_handle_at\fP(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 \fBO_PATH\fP w kolejnym
wywołaniu do \fBopen_by_handle_at\fP(2). Ten deskryptor pliku można użyć w
opisanych wcześniej wywołaniach systemowych, aby działać na samym dowiązaniu
symbolicznym.
.SS "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 \fIpodąża\fP 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).
.P
Konieczne jest omówienie trzech odrębnych przypadków. Oto one:
.IP \[bu] 3
Dowiązania symboliczne będące argumentami do wywołań systemowych.
.IP \[bu]
Dowiązania symboliczne będące argumentami wiersza poleceń do narzędzi, które
nie przechodzą przez drzewo plików.
.IP \[bu]
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).
.P
.\"
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ć \fIa/b/c\fP, część poprzedzająca ostatni ukośnik (tj. \fIa/b\fP)
jest nazywana składową \fIdirname\fP (katalogową), a część po ostatnim ukośniku
(tj. \fIc\fP) jest nazywana składową \fIbasename\fP (podstawową).
.SS "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.
.P
Dowiązania symboliczne w ścieżce przekazywanej do wywołania systemowego są
traktowane następująco:
.IP (1) 5
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 \fBopenat2\fP(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).
.IP (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 \fIslink\fP
wskazujące na plik o nazwie \fIafile\fP, to wywołanie systemowe \fIopen("slink" \&...\&)\fP zwróciłoby deskryptor pliku odnoszący się do pliku \fIafile\fP.
.P
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: \fBlchown\fP(2), \fBlgetxattr\fP(2), \fBllistxattr\fP(2),
\fBlremovexattr\fP(2), \fBlsetxattr\fP(2), \fBlstat\fP(2), \fBreadlink\fP(2),
\fBrename\fP(2), \fBrmdir\fP(2) oraz \fBunlink\fP(2).
.P
.\" Maybe one day: .BR fchownat (2)
Pewne inne wywołania systemowe opcjonalnie podążają za dowiązaniami
symbolicznymi w składowej basename (podstawowej) ścieżki. Są to:
\fBfaccessat\fP(2), \fBfchownat\fP(2), \fBfstatat\fP(2), \fBlinkat\fP(2),
\fBname_to_handle_at\fP(2), \fBopen\fP(2), \fBopenat\fP(2), \fBopen_by_handle_at\fP(2) i
\fButimensat\fP(2); więcej szczegółów w innych podręcznikach systemowych. Jako
że \fBremove\fP(3) jest aliasem \fBunlink\fP(2), ta funkcja biblioteczna nie
podąża za dowiązaniami symbolicznymi. Gdy do dowiązania symbolicznego
zastosuje się \fBrmdir\fP(2), to wywołanie zawiedzie z błędem \fBENOTDIR\fP.
.P
\fBlink\fP(2) zasługuje na odrębny opis. POSIX.1\-2001 określa, że \fBlink\fP(2)
powinno rozwiązywać \fIoldpath\fP, 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.
.SS "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.
.P
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 \fIslink\fP wskazujące na plik o nazwie
\fIafile\fP, polecenie \fIcat slink\fP wyświetliłoby zawartość pliku \fIafile\fP.
.P
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 \fIchown file\fP, natomiast nie dotyczy polecenia \fIchown\ \-R file\fP,
ponieważ przechodzi ono przez drzewo plików (to ostatnie stanowi trzeci
przypadek, opisany w podrozdziale poniżej).
.P
Jeśli wyraźnym zamiarem jest działanie polecenia na samym dowiązaniu
symbolicznym, zamiast podążanie za nim \[em] np. jeśli chce się zmienić za
pomocą \fIchown slink\fP własność pliku \fIslink\fP, niezależnie od tego, czy jest
to dowiązanie symboliczne, czy też nie \[em] powinno się zastosować opcję
\fI\-h\fP. W powyższym przykładzie \fIchown root slink\fP zmieniłoby własność
pliku, do którego odnosi się \fIslink\fP, natomiast \fIchown\ \-h root slink\fP
zmieniłoby własność samego \fIslink\fP.
.P
Od tej reguły istnieją pewne wyjątki:
.IP \[bu] 3
Polecenia \fBmv\fP(1) i \fBrm\fP(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).
.IP \[bu]
Polecenie \fBls\fP(1) również jest wyjątkiem od tej reguły. Ze względu na
kompatybilność z dawnymi systemami (gdy \fBls\fP(1) nie przechodzi przez drzewo
\[em] tj. nie podano opcji \fI\-R\fP), polecenie \fBls\fP(1) podąża za dowiązaniami
symbolicznymi podanymi jako argumenty, jeśli podano opcje \fI\-H\fP lub \fI\-L\fP,
albo gdy nie podano opcji \fI\-F\fP, \fI\-d\fP lub \fI\-l\fP (polecenie \fBls\fP(1) jest
jedynym poleceniem, gdzie opcje \fI\-H\fP i \fI\-L\fP wpływają na jego zachowanie,
nawet gdy nie jest dokonywane przejście przez drzewo plików).
.IP \[bu]
.\"
.\"The 4.4BSD system differs from historical 4BSD systems in that the
.\".BR chown (1)
.\"and
.\".BR chgrp (1)
.\"commands follow symbolic links specified on the command line.
Polecenie \fBfile\fP(1) również jest wyjątkiem od tej reguły. Polecenie
\fBfile\fP(1) nie podąża za dowiązaniami symbolicznymi, podanymi jako
argument. Polecenie \fBfile\fP(1) podąża za dowiązaniami symbolicznymi podanymi
jako argument, gdy podano opcję \fI\-L\fP.
.SS "Polecenia przechodzące przez drzewo plików"
Polecenia, które albo opcjonalnie, albo zawsze przechodzą przez drzewo
plików: \fBchgrp\fP(1), \fBchmod\fP(1), \fBchown\fP(1), \fBcp\fP(1), \fBdu\fP(1),
\fBfind\fP(1), \fBls\fP(1), \fBpax\fP(1), \fBrm\fP(1) i \fBtar\fP(1).
.P
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ń.
.P
\fIPierwsza reguła\fP 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.
.P
Polecenie \fIrm\ \-r slink directory\fP usunie \fIslink\fP, oraz wszelkie
dowiązania symboliczne napotkane przy przechodzeniu drzewa katalogu
\fIdirectory\fP, ponieważ dowiązania symboliczne mogą być usuwane. W żadnym
przypadku \fBrm\fP(1) nie będzie dotyczyć pliku wskazywanego przez \fIslink\fP.
.P
\fIDruga reguła\fP 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
\[Bq]fizycznym\[rq], w odróżnieniu od przejścia \[Bq]logicznego\[rq] (gdy
podąża się za dowiązaniami symbolicznymi odnoszącymi się do katalogów).
.P
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:
.IP \[bu] 3
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ę \fI\-H\fP (od ang \[Bq]half\-logical\[rq]
\[em] \[Bq]półlogiczny\[rq]). 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
\fI\-H\fP zostanie zignorowana, jeśli nie podano również \fI\-R\fP).
.IP
Dla przykładu, polecenie \fIchown\ \-HR user slink\fP przejdzie przez hierarchię
plików zakorzenionych w pliku, na który wskazuje \fIslink\fP. Proszę zauważyć,
że \fI\-H\fP nie jest tym samym, co opisywana wcześniej opcja \fI\-h\fP. Opcja \fI\-H\fP
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.
.IP \[bu]
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ę \fI\-L\fP (\[Bq]logiczny\[rq]). 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 \fI\-L\fP zostanie zignorowana, jeśli nie podano również
\fI\-R\fP).
.IP
Dla przykładu, polecenie \fIchown\ \-LR user slink\fP zmieni właściciela pliku,
do którego odnosi się \fIslink\fP. Jeśli \fIslink\fP wskazuje na katalog, \fBchown\fP
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 \fBchown\fP, zostaną potraktowane w ten
sam sposób co \fIslink\fP.
.IP \[bu]
Można sprawić, aby polecenie zachowało się w sposób domyślny podając opcję
\fI\-P\fP (od ang. \[Bq]physical\[rq] \[em] \[Bq]fizyczny\[rq]). Opcja ta ma na
celu upodobnienie całej przestrzeni nazw do fizycznej przestrzeni nazw.
.P
W przypadku poleceń, które domyślnie nie przechodzą przez drzewo plików,
opcje \fI\-H\fP, \fI\-L\fP i \fI\-P\fP są ignorowane, jeśli nie poda się równocześnie
opcji \fI\-R\fP. Dodatkowo, można podać opcje \fI\-H\fP, \fI\-L\fP i \fI\-P\fP 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ń.
.P
Polecenia \fBls\fP(1) i \fBrm\fP(1) mają wyjątki do tych reguł:
.IP \[bu] 3
Polecenie \fBrm\fP(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 \fBrm\fP(1) nie obsługuje opcji \fI\-H\fP, \fI\-L\fP ani \fI\-P\fP.
.IP \[bu]
Aby zachować kompatybilność z dawnymi systemami, polecenie \fBls\fP(1) działa
nieco odmiennie. Jeśli nie poda się opcji \fI\-F\fP, \fI\-d\fP lub \fI\-l\fP, \fBls\fP(1)
będzie podążało za dowiązaniami symbolicznymi podanymi w wierszu
poleceń. Jeśli poda się opcję \fI\-L\fP, \fBls\fP(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.
.SH "ZOBACZ TAKŻE"
\fBchgrp\fP(1), \fBchmod\fP(1), \fBfind\fP(1), \fBln\fP(1), \fBls\fP(1), \fBmv\fP(1),
\fBnamei\fP(1), \fBrm\fP(1), \fBlchown\fP(2), \fBlink\fP(2), \fBlstat\fP(2),
\fBreadlink\fP(2), \fBrename\fP(2), \fBsymlink\fP(2), \fBunlink\fP(2), \fButimensat\fP(2),
\fBlutimes\fP(3), \fBpath_resolution\fP(7)
.PP
.SH TŁUMACZENIE
Autorami polskiego tłumaczenia niniejszej strony podręcznika są:
Michał Kułach <michal.kulach@gmail.com>
.
.PP
Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach
licencji można uzyskać zapoznając się z
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License w wersji 3
.UE
lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.
.PP
Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy
dyskusyjnej
.MT manpages-pl-list@lists.sourceforge.net
.ME .
