Linux Certif

Toute la documentation sur la certification Linux LPI

Rechercher une page de manuel

AF_UNIX

NAZWA

unix, PF_UNIX, AF_UNIX, PF_LOCAL, AF_LOCAL - gniazda lokalnej komunikacji miêdzyprocesowej

SK£ADNIA

#include <sys/socket.h>
#include <sys/un.h>

unix_socket = socket(PF_UNIX, type, 0);
error = socketpair(PF_UNIX, type, 0, int *sv);

OPIS

Rodzina gniazd PF_UNIX (znana równie¿ jako PF_LOCAL) s³u¿y do wydajnej komunikacji pomiêdzy procesami na tej samej maszynie. Gniazda uniksowe mog± byæ albo anonimowe (tworzone przez socketpair(2)), albo skojarzone z plikiem typu gniazda. Linux wspiera równie¿ abstrakcyjn±, niezale¿n± od systemu plików przestrzeñ nazw.

Prawid³owe typy to SOCK_STREAM dla gniazd strumieniowych, SOCK_DGRAM dla gniazd datagramowych, które zachowuj± granice komunikatów (w przypadku wiêkszo¶ci implementacji Uniksa gniazda uniksowe s± zawsze niezawodne i nie zmieniaj± kolejno¶ci datagramów), oraz (od wersji j±dra 2.6.4) SOCK_SEQPACKET dla gniazd zorientowanych po³±czeniowo, które zachowuj± granice komunikatu i dostarczaj± komunikaty w kolejno¶ci ich wysy³ania.

Za po¶rednictwem pomocniczych danych mo¿na poprzez gniazda uniksowe przekazywaæ do innych procesów deskryptory plików i uwierzytelnianie procesów.

FORMAT ADRESU

Adres gniazda uniksowego jest zdefiniowany jako nazwa pliku w systemie plików lub jako unikatowy ³añcuch w abstrakcyjnej przestrzeni nazw. Gniazda utworzone za pomoc± socketpair(2) s± anonimowe. Dla gniazd nieanonimowych adres docelowy mo¿na ustawiæ za pomoc± connect(2). Adres lokalny mo¿na ustawiæ za pomoc± bind(2). Gdy gniazdo jest po³±czone, ale nie posiada jeszcze adresu lokalnego, jest mu przypisywany automatycznie wygenerowany unikatowy adres w abstrakcyjnej przestrzeni nazw.

 #define UNIX_PATH_MAX    108
 
 struct sockaddr_un {
     sa_family_t    sun_family;               /* AF_UNIX */
     char           sun_path[UNIX_PATH_MAX];  /* ¶cie¿ka dostêpu */
 };
 

sun_family zawsze ma warto¶æ AF_UNIX. sun_path zawiera zakoñczon± znakiem null nazwê ¶cie¿ki dostêpu do gniazda w systemie plików. Gdy sun_path zaczyna siê bajtem zerowym ('' '), odnosi siê do abstrakcyjnej przestrzeni nazw, któr± zarz±dza modu³ protoko³u Unix. Adres gniazda w tej przestrzeni nazw stanowi± pozosta³e bajty sun_path. Nale¿y zauwa¿yæ, ¿e nazwy w abstrakcyjnej przestrzeni nazw nie s± zakoñczone znakiem null.

OPCJE GNIAZD

Ze wzglêdów historycznych nastêpuj±ce opcje gniazd s± podawane przy typie SOL_SOCKET, pomimo ¿e s± one specyficzne dla PF_UNIX. Mo¿na je ustawiæ za pomoc± setsockopt(2), a odczytaæ za pomoc± getsockopt(2) podaj±c SOL_SOCKET jako rodzinê gniazd.

SO_PASSCRED

W³±cza otrzymywanie uwierzytelnieñ od procesu wysy³aj±cego komunikat pomocniczy. Przy w³±czonej tej opcji i nie po³±czonym jeszcze gnie¼dzie, unikatowa nazwa gniazda z abstrakcyjnej przestrzeni nazw jest generowana automatycznie. Oczekiwany jest logiczny znacznik typu ca³kowitego.

CECHY (NIE)WSPIERANE

W olejnych paragrafach opisano pewnie szczegó³y implementacji API gniazd domeny Unix specyficzne dla Linuksa oraz cechy niewspierane.

Gniazda strumieniowe z domeny uniksowej nie obs³uguj± zawiadomienia o danych autonomicznych (flaga MSG_OOB funkcji send(2) i recv(2)).

Flaga MSG_MORE funkcji send(2) nie jest obs³ugiwana dla gniazd domeny Unix.

Opcje SO_SNDBUF dzia³a w przypadku gniazd domeny uniksowej, ale opcja SO_RCVBUF ju¿ nie. Dla gniazd datagramowych warto¶æ SO_SNDBUF nak³ada górny limit na rozmiar wychodz±cych datagramów. Limit ten jest liczony jako podwojona (patrz socket(7)) warto¶æ opcji minus 32 bajty wymagane na informacje nie bêd±ce danymi.

KOMUNIKATY POMOCNICZE

Dane pomocnicze s± wysy³ane i odbierane za pomoc± sendmsg(2) i recvmsg(2). Ze wzglêdów historycznych komunikaty pomocnicze poni¿szych typów s± podawane przy typie SOL_SOCKET, pomimo ¿e s± one specyficzne dla PF_UNIX. Aby je wys³aæ, nale¿y ustawiæ pole cmsg_level struktury cmsghdr na SOL_SOCKET a pole cmsg_type na typ. Wiêcej informacji mo¿na znale¼æ w cmsg(3).

SCM_RIGHTS

Odbieranie od innego procesu lub wysy³anie do niego zbioru otwartych deskryptorów plików. Porcja danych zawiera tablicê liczb ca³kowitych bêd±cych deskryptorami plików. Przekazane deskryptory plików zachowuj± siê tak, jakby zosta³y utworzone za pomoc± dup(2).

SCM_CREDENTIALS

Odbieranie lub wysy³anie uwierzytelnieñ uniksowych. Mo¿e s³u¿yæ do autoryzacji. Uwierzytelnienia s± przekazywane jako komunikat pomocniczy typu struct ucred.

 struct ucred {
     pid_t pid;  /* identyfikator procesu wysy³aj±cego */
     uid_t uid;  /* ident. u¿ytkownika procesu wysy³aj±cego */
     gid_t gid;  /* ident. grupy procesu wysy³aj±cego */
 };
 

  J±dro sprawdza uwierzytelnienia podane przez wysy³aj±cego. Proces o efektywnym ID u¿ytkownika równym 0 mo¿e podaæ warto¶ci, które ró¿ni± siê od jego w³asnych. W pozosta³ych przepadkach wysy³aj±cy musi podaæ swój w³asny identyfikator procesu (o ile nie ma ustawionego znacznika CAP_SYS_ADMIN), swój w³asny identyfikator u¿ytkownika, efektywny identyfikator u¿ytkownika lub ustawiony identyfikator u¿ytkownika (o ile nie ma ustawionego znacznika CAP_SETUID) oraz swój w³asny identyfikator grupy, efektywny identyfikator grupy lub ustawiony identyfikator grupy (o ile nie ma ustawionego znacznika CAP_SETGID). Aby otrzymaæ komunikat typu struct ucred, dla gniazda musi byæ w³±czona opcja SO_PASSCRED.

WERSJE

SCM_CREDENTIALS oraz abstrakcyjna przestrzeñ nazw zosta³y wprowadzone w Linuksie 2.2 i nie nale¿y ich u¿ywaæ w przeno¶nych programach. (Niektóre systemy wywodz±ce siê z BSD równie¿ wspieraj± przekazywanie uwierzytelnieñ, ale implementacje ró¿ni± siê w szczegó³ach.)

UWAGI

W linuksowej implementacji, gniazda widoczne w systemie plików stosuj± siê do uprawnieñ katalogu, w którym siê znajduj±. Ich w³a¶ciciela, grupê oraz prawa dostêpu mo¿na zmieniaæ. Gdy proces nie posiada praw zapisu i przeszukiwania (uruchamiania) do katalogu, w którym tworzone jest gniazdo, jego utworzenie siê nie powiedzie. Po³±czenie z obiektem gniazda wymaga praw odczytu/zapisu. Takie zachowanie ró¿ni siê od zachowania wielu systemów wywodz±cych sie z BSD, które ignoruj± uprawnienia dla gniazd uniksowych. Programy przeno¶ne ze wzglêdów bezpieczeñstwa nie powinny polegaæ na tej cesze.

W trakcie ³±czenia siê z gniazdem posiadaj±cym nazwê pliku, tworzone jest plik specjalny gniazda w systemie plików, który musi zostaæ skasowany przez wywo³uj±cego, gdy ju¿ nie bêdzie potrzebny (za pomoc± unlink(2)). Stosuje siê tu zwyk³a uniksowa sk³adnia opó¼nionego zamkniêcia (ang. close-behind); gniazdo mo¿na skasowaæ w dowolnym momencie, a zostanie ono ostatecznie usuniête z systemu plików po zamkniêciu ostatniego odwo³ania do niego.

Aby przekazaæ deskryptory plików lub uwierzytelnienia poprzez SOCK_STREAM trzeba wys³aæ/odebraæ co najmniej jeden bajt niepomocniczych danych w tym samym wywo³aniu sendmsg() lub recvmsg()

Gniazda strumieniowe z domeny uniksowej nie obs³uguj± zawiadomienia o danych autonomicznych.

B£ÊDY

ENOMEM

Brak pamiêci.

ECONNREFUSED

Wywo³ano connect(2) dla obiektu gniazda, który nie nas³uchuje. Mo¿e siê to zdarzyæ, gdy zdalne gniazdo nie istnieje lub nazwa pliku nie odnosi siê do gniazda.

EINVAL

Podano nieprawid³owy argument. Najczêstsz± przyczyn± jest brak ustawionego AF_UNIX w polu sun_type przekazywanych gniazdu adresów lub nieprawid³owy dla danej operacji stan gniazda.

EOPNOTSUPP

Operacja strumieniowa wywo³ana dla gniazda niestrumieniowego lub próba u¿ycia opcji danych autonomicznych.

EPROTONOSUPPORT

Podanym protoko³em nie jest PF_UNIX.

ESOCKTNOSUPPORT

Nieznany typ gniazda.

EPROTOTYPE

Typ gniazda zdalnego ró¿ni siê od typu gniazda lokalnego (SOCK_DGRAM wobec SOCK_STREAM)

EADDRINUSE

Wybrany adres lokalny jest zajêty lub obiekt gniazda w systemie plików ju¿ istnieje.

EISCONN

Wywo³ano connect(2) dla ju¿ po³±czonego gniazda lub podano adres docelowy dla po³±czonego gniazda.

ENOTCONN

Operacja na gnie¼dzie wymaga adresu docelowego, a gniazdo nie jest po³±czone.

ECONNRESET

Zdalne gniazdo zosta³o nieoczekiwanie zamkniête.

EPIPE

Zdalne gniazdo strumieniowe zosta³o zamkniête. Gdy w³±czone, wysy³any jest jednocze¶nie sygna³ SIGPIPE. Mo¿na tego unikn±æ przekazuj±c znacznik MSG_NOSIGNAL do sendmsg(2) lub recvmsg(2).

EFAULT

Nieprawid³owy adres pamiêci u¿ytkownika.

EPERM

Wysy³aj±cy poda³ nieprawid³owe uwierzytelnienia w struct ucred.

Inne b³êdy mog± zostaæ wygenerowane przez podstawow± warstwê gniazd lub przez system plików podczas tworzenia obiektu gniazda w systemie plików. Wiêcej informacji mo¿na znale¼æ na odpowiednich stronach podrêcznika.

ZOBACZ TAK¯E

recvmsg(2), sendmsg(2), socket(2), socketpair(2), cmsg(3), capabilities(7), socket(7)