UNIX-Domänen-Sockets, die nicht für Benutzer zugänglich sind?

Ich verwende eine Client/Server-Anwendung auf Red Hat Enterprise unter Verwendung von ZMQ zur Nachrichtenübergabe. Der IPC-Socket, der verwendet wird, um einen Client mit dem Server zu verbinden, wird unter Verwendung eines Unix-Domain-Sockets implementiert.UNIX-Domänen-Sockets, die nicht für Benutzer zugänglich sind?

Wenn Benutzer A den Serverprozess startet, scheint es, als ob nur Clients, die von Benutzer A gestartet wurden, eine Verbindung zu diesem Socket herstellen und über diesen kommunizieren können. Unser Projekt erfordert, dass die Clients von verschiedenen Benutzern ausgeführt werden können. Dies ist ein wichtiger Knackpunkt.

Der Socket befindet sich unter/tmp/ipc_assoc mit 755-Standardberechtigungen. chmod 777 behebt das Problem nicht. chown BenutzerB ermöglicht Benutzer B Zugriff auf den Socket, aber Benutzer A verliert dann den Zugriff. Nicht einmal Root kann auf den Socket zugreifen. Auf dem Gerät wird keine ACL oder SeLinux verwendet.

Ist dieses typische Verhalten für Unix-Domain-Sockets? Hat jemand herausgefunden, wie man damit umgehen kann?

Quelle

2010-08-11 Dana Leonard

Mit etwas Hilfe von der ZMQ-Mailingliste habe ich eine Arbeit gemacht. Es ist hässlich, aber scheint konsequent zu arbeiten.

Ich musste ein Unterverzeichnis unter/tmp und chmod 777 es machen. Der Server erstellt jetzt den Socket in diesem neuen Ordner. Es auch programmatisch chmod 777 der Sockel. Solange der Server als root ausgeführt wird, kann jeder Benutzer einen Client ausführen und mit dem Server sprechen.

Ich weiß nicht, warum UNIX-Domain-Socket auf diese Weise verhalten, aber es ist sicher ärgerlich.

Quelle

2010-08-11 14:19:29

Warum funktioniert 777, während 770 nicht funktioniert? Ich bin verwirrt, ich habe beide Benutzer unter die gleiche Gruppe und nicht gehen ... – knocte

Haben Sie versucht, UserA und UserB einer gemeinsamen Benutzergruppe hinzuzufügen?

Quelle

2010-08-11 12:09:14

Jeder scheint bereits in der gleichen Gruppe zu sein. –

Ist ein symbolischer Link zu einer anderen Datei mit anderen Berechtigungen? –

Nein, wenn Sie 'ls -l' auf dem Socket ausführen, wird" srwxr-xr-x ... ipc_assoc "ausgedruckt –

chmod (s.sun_path, 0777); nach dem Anhören der Steckdose.

domain = AF_UNIX; 
name = servname; 
port = -1; 

n = MakeLocalSocket(s); 
if (n == 0) { 
    fatal("can't create socket"); 
} 

unlink(s.sun_path); 

if (bind(fd, & s, n) < 0) { 
    fatal("can't bind socket"); 
} 

if (listen(fd, 5) != 0) { 
    fatal("can't listen to socket"); 
} 

/* UNIX domain sockets need to be mode 777 on 4.3 */ 
chmod(s.sun_path, 0777);

Quelle

2012-12-12 14:57:25 Homer6

Warum funktioniert 777, während 770 nicht? Ich bin verwirrt, ich habe beide Benutzer unter die gleiche Gruppe und nicht gehen ... – knocte

Nicht sicher. Laut http://man7.org/linux/man-pages/man7/unix.7.html "macht POSIX jedoch keine Aussage über die Auswirkungen der Berechtigungen auf eine Socket-Datei und auf einige Systeme (z. B. älteren BSDs) werden die Socket-Berechtigungen ignoriert. Portable Programme sollten sich aus Sicherheitsgründen nicht auf diese Funktion verlassen. " – Homer6

tatsächlich löste ich das Problem: Der Benutzer, den ich der Gruppe hinzugefügt hatte, musste sich erneut anmelden, damit diese Änderung wirksam wurde! aber danke für deinen Kommentar – knocte

vorübergehend die umask ändern:

mode_t umask_ = umask(0000); /* let the socket be mode 0777 so that other users can connect */ 
int err = bind(fd, (struct sockaddr *)&unix_bind_addr, sizeof(unix_bind_addr)); 
umask(umask_); /* restore old umask (0777 is a pretty bad choice for normal stuff) */ 
if (err) { 
    /* handle bind error here */ 
}

Natürlich ist dies eine schlechte Idee, wenn Sie Threads verwenden.

Quelle

2013-03-01 21:28:11 thejh

UNIX-Domänen-Sockets, die nicht für Benutzer zugänglich sind?

Antwort

Verwandte Themen