Programm als anderer Benutzer, Drag & Drop funktioniert nicht

[User 50673]

Die tatsächliche Implementierung des PBS benötigt das nicht. Der schreibende Prozess stellt seine Daten in seinem Adressraum zur Verfügung. Der PBS holt die sich dann (lesend).

Warum sollte er das tun? Wie ich schon sagte, sind die Datenbereiche der Prozesse gegeneinander abgeschottet. Somit entfällt auch eine Lesezugriff.

Der Zielprozess liest die Daten ohnehin nur.

Unbestritten.

Nie muss in fremden Speicher geschrieben werden.

Richtig. Dennoch plädiere ich für einen gemeinsam genutzten Datenbereich. (Siehe mein Post) Der Nutzerprozess legt seine Clipboard-Daten in diesen ab und der PBS holt sie sich dort ab. Die Zugriffsverwaltung übernimmt der Scheduler des Betriebsystems. (Semaphore,Mutexe, Monitore...)

 

[Amin Negm-Awad]

Warum sollte er das tun? Wie ich schon sagte, sind die Datenbereiche der Prozesse gegeneinander abgeschottet. Somit entfällt auch eine Lesezugriff.

Der andere Prozess erhält Leserechte. Ich suche das heute Abend mal im Singh heraus.Irgendwie muss aber der Datentransfer erfolgen. Der Zielprozess benötigt bloß keine Schreibrechte.

Unbestritten.

Das sagst du. Die Expertenrunde meint aber, es seien Schreibrechte notwendig. Und das lustigerweise aber nicht bei einer IPC zwischen Prozessen desselben Nutzers, sondern nur dann, wenn mehrere User beteiligt sind. Dabei haben Speicherrechte mit demNutzer nichts zu tun.

Richtig. Dennoch plädiere ich für einen gemeinsam genutzten Datenbereich. (Siehe mein Post) Der Nutzerprozess legt seine Clipboard-Daten in diesen ab und der PBS holt sie sich dort ab. Die Zugriffsverwaltung übernimmt der Scheduler des Betriebsystems. (Semaphore,Mutexe, Monitore...)

Ich kann nicht beurteilen, wofür du plädierst. Einfacher ist das, weil schneller und weniger kompliziert im Handling. Letztlich aber ohnehin egal: Selbst wenn man den einrichtet, dann muss der zwischen den Prozessen geteilt sein. Wem die Prozesse gehören, ist immer noch gleichgültig.

Die beiden meinen ja, dass der Datenaustausch zwischen Prozessen desselben Nutzers ungefährlich, zwischen denen verschiedener Nutzer gefährlich sei. Technisch ist das aber dasselbe, weil sich die Speicherzugriffsrechte ohnehin immer nur nach dem Prozess richten.

Falls man also in geteilten Speicherbereichen eine Gefahr sieht, dann muss man die bereits innerhalb eines Nutzers sehen.

Wie du das implementieren willst, ist da eigentlich gleichgültig. An der Zuordnung des Speichers zu einem Prozess ändert das nichts. Meinetwegen tauschen die Prozesse die Daten mittels handschriftlichen Notizzetelln, doppelt unterschrieben, gefertigt in Zaubertinte aus. Das ändert dann immer noch nichts daran, dass der Speicher zwischen Prozessen abgeschottet ist und nicht zwischen Usern.

 

[User 50673]

Die Interprozesskommunikation findet (meines Wissens nach) auf einem sehr viel niedrigerem Level als die Benutzertrennung statt. Daraus folgt, dass die IPC nicht den Benutzerrechten untergeorndet ist. Alle Prozesse sind gegeneinander abgeschottet.

Eben. Die Implementation sei dahingestellt. Wahrscheinlich ist jedoch, dass die Prozesse entweder über message passing interagieren oder über einen gemeinsamen Datenbereich.

Hier ein Beispiel zur nachrichtenbasierten Kommunikation:

 

[Rastafari]

Die Interprozesskommunikation (meines Wissens nach) findet auf einem sehr viel niedrigerem Level als die Benutzertrennung statt.

Nein, auf dem gleichen.
Unterhalb des "absoluten Nullpunkts" (aka Kernel) gibt es nichts mehr.

 

[User 50673]

Nein, auf dem gleichen.
Unterhalb des "absoluten Nullpunkts" (aka Kernel) gibt es nichts mehr.

Da gibts noch ne ganze Menge... nebenbei die IPC läuft im Kernel level, wobei die Benutzertrennung im User level stattfindet. Womit ich meine Aussage hier bestätigt sehe.

PS: Grafik System V/3, worauf noch heute jedes moderne Unix aufbaut.

 

[Rastafari]

die Benutzertrennung im User level stattfindet.

Ohne bereits erfolgte Benutzertrennung gibt es gar keinen "User Level". Das eine ist zwingende Voraussetzung der Existenz des anderen.
Die Benutzerkontentrennung wird aktiv, sobald der Kernel von Single-User auf Multiusermodus umschaltet.

BTW
In dieser Grafik befinden sich "Interprozesskommunikation" und "Prozessverwaltung" auf unterschiedlichen Ebenen? Tatsächlich?

 

[User 50673]

Ohne bereits erfolgte Benutzertrennung gibt es gar keinen "User Level". Das eine ist zwingende Voraussetzung der Existenz des anderen.
Die Benutzerkontentrennung wird aktiv, sobald der Kernel von Single-User auf Multiusermodus umschaltet.

Völlig richtig was du da sagst, jedoch am Thema vorbei.

Die Prozesskommunikation wird im kernel-mode ausgeführt. Die Umschaltung erfolgt noch im user-mode. Dabei wird der aktuelle Kontext des Users gesichert und eine Umschaltung in den kernel-mode wird vorgenommen. Dann läuft die IPC. Sobald die terminiert, wird wieder in den Benutzermodus zurück gewechselt.

Das verdeutlicht auch diese schöne Grafik:

Das entspricht auch dem Design im Sinne der Schutzebenen eines Prozessors. Siehe diese Grafik:

Damit sei auch bewiesen, dass die Nutzertrennung des Betriebsystems nicht die einzige Abgrenzung von Berechtigungen darstellt.

 

[Amin Negm-Awad]

Die Interprozesskommunikation findet (meines Wissens nach) auf einem sehr viel niedrigerem Level als die Benutzertrennung statt. Daraus folgt, dass die IPC nicht den Benutzerrechten untergeorndet ist. Alle Prozesse sind gegeneinander abgeschottet.

Eben, wobei man das nicht einmal so festlegen muss. Wichtig für diese Diskussion ist alleine, dass die Interprozesskommunikation eine Frage der Prozesssteuerung und nicht der Benutzersteuerung ist. IPC benötige ich auch bei 1-Benutzer-Systemen. Es ist eben wie schon mehrfach gesagt eine Frage der Prozesse, nicht eine Frage der Benutzer.

Eben. Die Implementation sei dahingestellt. Wahrscheinlich ist jedoch, dass die Prozesse entweder über message passing interagieren oder über einen gemeinsamen Datenbereich.

Ja, wahrscheinlich ist das. Aber wie gesagt sogar eigentlich gleichgültig. Entscheidend ist hier, dass die Benutzerkontrolle damit nichts am Hut hat. Deshalb spielt es keine Rolle, ob die Prozesse demselben Benutzer gehören. Wenn ich einmal IPC wischen Prozessen desselben Nutzers akzeptiere, akzeptiere ich automatisch damit auch die IPC zwischen Prozessen verschiedener Benutzer.

Damit ist eine Argumentation der Art: "Geteiltes Pasteboard zwischen Prozessen desselben Nutzers okay, zwischen Prozessen verschiedener Nutzer indessen gefährlich" schlicht falsch. Und darum ging es ja. (Geteiltes Pasteboard pro Nutzerprozesse bzw. pro Prozesse insgesamt.)

 

[Rastafari]

Die Umschaltung erfolgt noch im user-mode.

Nein. Die Umschaltung ist Aufgabe des Schedulers, der ebenfalls Teil des Kernelkontexts ist.
Ein im Userspace agierender Prozess besitzt lediglich die Möglichkeit diesem seinen Status zu signalisieren. Darauf kann der Scheduler auf unterschiedliche Weise reagieren und weitere Umschaltungen zum betreffenden Prozess vornehmen, oder auch nicht. (Die Zeiten des "kooperativen Multitasking" sind vorbei.)

 

[MacMark]

Die tatsächliche Implementierung des PBS benötigt das nicht. Der schreibende Prozess stellt seine Daten in seinem Adressraum zur Verfügung. Der PBS holt die sich dann (lesend). ...

Nein. App 1 schreibt in den Adreßraum des pbs und App 2 liest aus dem Adreßraum des pbs. Es gibt drei Adreßräume: Den von App 1, App 2 und den vom pbs.
http://developer.apple.com/mac/libr...cepts.html#//apple_ref/doc/uid/TP40008101-SW8

 

[Amin Negm-Awad]

Nein. App 1 schreibt in den Adreßraum des pbs und App 2 liest aus dem Adreßraum des pbs. Es gibt drei Adreßräume: Den von App 1, App 2 und den vom pbs.
http://developer.apple.com/mac/libr...cepts.html#//apple_ref/doc/uid/TP40008101-SW8

Nein, weil wie dort steht, der PBS den Speicherbereich im Quellprozess den Speicher zur Verfügung stellt. Der migriert in den Quellprozess.

Aber damit hast du gerade wunderbar belegt, dass es gar keinen Unterschied macht, welchem User der Prozess gehört. Den der von dir gedachte und angeblich so gefährliche Mechanismus findet also deiner Meinung nach bereits jetzt statt. Wieso sollte das dann eine Rolle spielen, welchem User der Prozess gehört?

 

[MacMark]

... spielt es keine Rolle, ob die Prozesse demselben Benutzer gehören. Wenn ich einmal IPC wischen Prozessen desselben Nutzers akzeptiere, akzeptiere ich automatisch damit auch die IPC zwischen Prozessen verschiedener Benutzer. ...

Nein. Die Kommunikation zwischen Prozessen unterschiedlicher Nutzer ist nochmal zusätzlich abgeschottet. Die (reale, effektive und gesicherte) UserID der Prozesse wird abgefragt im Kernel und abhängig davon weiter verfahren oder eben nicht.

 

[MacMark]

Nein, weil wie dort steht, der PBS den Speicherbereich im Quellprozess den Speicher zur Verfügung stellt. ...

Nein, der pbs kommt bei App-to-App zum Tragen. Was Du liest, ist der Teil vom Kopieren innerhalb einer App selbst. Von App1-to-App2 schreibt App1 in den Adreßraum des pbs-Prozesses.

 

[Amin Negm-Awad]

Nein, der pbs kommt bei App-to-App zum Tragen. Was Du liest, ist der Teil vom Kopieren innerhalb einer App selbst. Von App1-to-App2 schreibt App1 in den Adreßraum des pbs-Prozesses.

Immer noch. Wie du selbst sogar ganz richtig mal gesagt hast, geht das wegen der Prozessabschottung nicht. Der PBS stellt einen Speicherbereich im Adressraum des Quellprozesses zur Verfügung. Wäre der nicht Bestandteil des Quelladressraumes, könnte der Prozess gar nicht darauf schreiben.

Aber das ist immer noch egal, weil der von dir gedachte Mechanismus dann immer noch deiner Meinung nach die Prozessgrenzen sprengen würde und damit immer noch nichts mit Usern zu tun hat.

Es bleibt damit dabei, dass es für die IPC nicht auf Nutzer ankommt und deshalb IPC zwischen Prozessen verschiedener Nutzer nicht "gefährlicher" als IPC zwischen Prozessen desselben Nutzers ist. Denn IPC hat nichts mit Nutzern zu tun. Ebenso gut kannst du nach Ziffer 3 der Seriennummer des Macs unterscheiden.

 

[Amin Negm-Awad]

Nein. Die Kommunikation zwischen Prozessen unterschiedlicher Nutzer ist nochmal zusätzlich abgeschottet. Die (reale, effektive und gesicherte) UserID der Prozesse wird abgefragt im Kernel und abhängig davon weiter verfahren oder eben nicht.

Selbstverständlich wird das berücksichtigt, weil ein Systempasteboard unerwünscht ist. Das hat aber mit Sicherheitsaspekten nichts zu tun, sondern mit Funktionalität. Das hatte ich schon vor Ewigkeiten geschrieben.

 

[User 50673]

... Von App1-to-App2 schreibt App1 in den Adreßraum des pbs-Prozesses.

Bin ich blind? Das steht da doch überhaupt nicht. Da steht lediglich, dass NSPasteboard einen dritten Adressraum zur Verfügung stellt. Da steht nicht, dass dieser auch von anderen Prozessen geschrieben werden kann (darf, was auch immer).

NSPasteboard provides access to a third address space—a pasteboard server process (pbs)—that is always running in the background.

 

[MacMark]

... Der PBS stellt einen Speicherbereich im Adressraum des Quellprozesses zur Verfügung. Wäre der nicht Bestandteil des Quelladressraumes, ...

Apple:

when moving data between two different applications, and therefore two different address spaces, a third memory space gets involved so the data persists even in the absence of the source. NSPasteboard provides access to a third address space—a pasteboard server process (pbs)

 

[Amin Negm-Awad]

Apple:

Apple:
NSPasteboard provides access to a third address space—a pasteboard server process (pbs)

Und wie gesagt: Damit ist es immer noch gleichgültig, wem der Prozess gehört. Denn das ist eine Frage der Prozesssteuerung und nicht der Usersteuerung. Damit ist es gleichgültig, wem der Prozess gehört.

 

[Amin Negm-Awad]

Apple:

Ja, wie ich sagte: Der PBS blendet den Speicher in dem Quelladressraum ein.

Und wie gesagt: Damit ist es immer noch gleichgültig, wem der Prozess gehört. Denn das ist eine Frage der Prozesssteuerung und nicht der Usersteuerung. Damit ist es gleichgültig, wem der Prozess gehört.

 

[MacMark]

... gleichgültig, wem der Prozess gehört.

Nein. Du kannst nicht auf Adreßräume zugreifen, die zum Prozeß eines anderen Users gehören.
Jeder User hat eine eigene Instanz des pbs laufen.