Che cosa fa l'autorizzazione x (esegui) sui socket unix?

In base alla mia esperienza, un utente senza privilegi non può accedere al socket unix che non possiede senza x bit impostato. Cosa fa esattamente questo bit? Grazie

linux permissions unix-sockets

— Владимир Тюхтин
fonte

È l'autorizzazione sui socket o sulla directory?

— Rui F Ribeiro,

Su una presa. La directory ha la modalità 0755, quindi l'utente può osservare il contenuto. Socket ha la modalità 0644, quindi l'utente logicamente (che appartiene a "altri" perché non possiede un socket appartenente a un gruppo che possiede un socket) dovrebbe essere in grado di scrivere sul socket. Ma l'utente riceve il messaggio di rifiuto dell'autorizzazione a meno che la modalità 0777 non sia applicata al socket.

— Владимир Тюхтин,

@ ВладимирТюхтин, 0644significa solo l'autorizzazione di lettura per i membri del gruppo e "altri", quindi solo il proprietario sarebbe in grado di accedere al socket (poiché l'autorizzazione di scrittura lo controlla). 0666, o appena 0222non è necessaria l'autorizzazione in lettura, sarebbe sufficiente per consentire l'accesso a tutti. Ma, piuttosto che dare autorizzazioni a tutti, esaminerei l'utilizzo dei gruppi per consentire l'accesso.

— ilkkachu,

Niente, come posso vedere.

Il Linux pagina man unix (7) dice che i permessi della directory che contiene una presa applicano normalmente (cioè è necessario +xsu /fooper connettersi a /foo/sock, e +wsu /fooper creare /foo/sock) e che i write controlli di autorizzazione di collegamento alla presa in sé:

Su Linux, la connessione a un oggetto socket stream richiede l'autorizzazione di scrittura su quel socket; anche l'invio di un datagramma a un socket di datagramma richiede l'autorizzazione di scrittura su quel socket.

Apparentemente alcuni altri sistemi si comportano diversamente:

POSIX non rilascia alcuna dichiarazione sull'effetto delle autorizzazioni su un file socket e su alcuni sistemi (ad es. BSD precedenti), le autorizzazioni socket vengono ignorate. I programmi portatili non dovrebbero fare affidamento su questa funzione per motivi di sicurezza.

unix(4)su FreeBSD descrive requisiti simili. La pagina man di Linux non diceva se l'accesso al socket su alcuni sistemi ignora anche le autorizzazioni della directory .

La rimozione del xbit dal socket sembra avere l'effetto di dare un errore diverso nel tentativo di eseguire il socket, ma non c'è molta differenza pratica:

$ ls -l test.sock
srwxr-xr-x 1 user user 0 Jun 28 16:24 test.sock=
$ nc -U ./test.sock
Hello
$ ./test.sock
bash: ./test.sock: No such device or address
$ chmod a-x test.sock
$ nc -U ./test.sock
Hello
$ ./test.sock
bash: ./test.sock: Permission denied

(Ho anche provato che in effetti solo il wbit sembra importare per accedere al socket su Linux Debian 4.9.0.)

Forse i socket che intendevi avevano tutti i bit di autorizzazione rimossi dall'utente o intendevi i xbit nella directory?

— ilkkachu
fonte