[Vm-dev] [squeak-dev] File & Socket Handle Access
Das.Linux at gmx.de
Wed Aug 16 06:40:32 UTC 2017
Note that for example SqueakSSL makes a great effort to NOT break the abstraction barriers found in Squeak.
Yes, that makes SqueakSSL a little bit more convoluted than just handing over a Socket, but it works with the Way the NetworkPlugin works, and can work on any kind of socket…
But seeing that win/linux/mac _all_ "do in" sockets that have fds, it may be just practical to go for handing around fds, instead of copying around. I don't know about riscos, but Squeak does not run there and does not have a SqueakSSL implementation in the first place, currently. (Plan9 should us a fd, when supporting).
just my 2ct
: in the sense of the SICP, not in the sense of maliciously obstructing.
> On 16.08.2017, at 08:26, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> Hi Eliot,
> I don't share the security concerns in this matter, but here are two thoughts:
> 1) The OS handle would just be a number or another simple object? So, I would compare it to any other "reference" to an artifact manifested outside the image that could become invalid anytime. For example, any URL can be stored in-image yet become invalid after some time if the DNS entry would vanish.
> 2) On a conceptual level, I see no issues to mix objects of different abstraction levels in the image. We do it all the time. A person might be represented as an instance of some Person class that points to an SqlDatabase that points to an SqlTable that points to a DirectoryEntryFile that points to a FileStream that ... and so on. We would just promote/offer the existing abstraction of OS handles to the object-oriented world.
> It would be unfortunate if security concerns would negatively affect consistency in this regard.
>> Am 16.08.2017 02:13:50 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>> Hi All,
>> recently Denis Kudriashov wanted to access the OS handle of a Socket from the image to pass through the FFI. David Lewis pointed out that the AioPlugin provides a primitive to do this. I asked David why he didn't add it to the SocketPlugin in the first place and he discussed Andreas Rabb's security concerns. It strikes me
>> a) that accessing the OS handle of a file or a socket is extremely useful in some circumstances and invalid in others
>> b) having handle access in a secondary plugin is inconvenient to say the least
>> c) having access only to Socket handles and not to file handles is also inconvenient.
>> So I propose adding a SecurityPlugin facility to control handle access, which would be granted by default, and to add primitives to both the SocketPlugin and FilePlugin to answer the native OS handle when the SecurityPlugin grants permission.
>> I also propose adding a compilation flag to the Windows VM to allow compiling out Andreas' handle management, which consists merely of maintaining a table of the file handles (not the socket handles) that have been created by the VM. It strikes me that a much better solution is merely to encrypt the handle via xoring with a value created at random. I don't see how Andreas' solution adds value, especially since it is not implemented on other platforms, and merely adds overhead.
>> Thoughts? Objections?
>> best, Eliot
More information about the Vm-dev