[squeak-dev] What is primitiveDropRequestFileHandle and do we really need it?

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Thu Aug 20 11:41:25 UTC 2020


Hi Vanessa,


thanks for the pointer to capability-based security, this makes sense! However in the OSVM source, I could not find any implementation of dropRequestFileHandle() that would not call dropRequestFileName() and sqFileOpen(), so I believe capability-based security is not actually used at the moment. Still, this hook could be relevant when a new platform (for instance, Android?) would be supported by OSVM. So for now, I conclude that one should indeed use both primitives as implemented in the latest Trunk, in order not to comprise this possibility for future implementations.


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Vanessa Freudenberg <vanessa at codefrau.net>
Gesendet: Mittwoch, 19. August 2020 23:42:52
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] What is primitiveDropRequestFileHandle and do we really need it?

A file handle can be a capability (*). A file name is a string.  The Squeak process may lack the permissions to open a named file, but could still read from an open handle (which maybe was created by the OS using a direct user gesture). That way, a sandboxed app can only access files that were explicitly granted permission by the user, rather than all files on the disk.

Secondly, it allows the use of temporary files - the file can be opened (which creates the handle) and deleted (which deletes its directory entry). The contents can still be read from the handle afterwards (at least on unix)

Vanessa

(*) https://en.wikipedia.org/wiki/Capability-based_security

On Wed, Aug 19, 2020 at 11:26 AM Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>> wrote:

Hi all,


as some of you already might have noticed [1, 2], I am currently working at a more powerful Drag and Drop (DnD) handling at the VM level of Squeak, heavily inspired by Marcel's ideas. While studying the existing source code, I was wondering what is the actual purpose of primitiveDropRequestFileHandle compared to primitiveDropRequestFileName which both are called by StandardFileStream >> #requestDropStream:.

I had a very short look at all the different DropPlugin implementations and in a nutshell, dropRequestFileHandle appears to call dropRequestFileName and then sqFileOpen() that path using the FilePlugin. Compared to this, the regular primitiveFileOpen from the FilePlugin which is called by StandardFileStream >> #open:forWrite: leads to fileOpenNamesizewritesecure() which first performs some ominous security checks (basically whether the file path is valid and the file is writable if needed) and then, again, calls sqFileOpen().


So at the end of the day, both primitives appear to call the same logic. So please allow me my naive question: Does anyone remember or imagine any good reason why we have an additional primitive for this purpose? My overall guess (from what I have learned so far about the VM side) would have been that you should be as frugal as possible when it comes to introducing a primitive, because developing, debugging, and exploring VM code is so much less simple and intuitive than Smalltalk code. For this reason, I would not expect to find any redundant "convenience primitives" in the OSVM interface.


I have two hypothetical explanations so far which however both I do not find satisfying:


  *   Optimization: Could there have been some ancient times where it might have been wise to save a redundant call to the SecurityPlugin after you have got a trusted file path from the host system?
  *   Buggy SecurityPlugin: Could there be any situation in which the SecurityPlugin would refuse a special file path returned by the DropPlugin though it can be opened by sqFileOpen()? But I cannot experience such a situation.

<http://www.hpi.de/>

Tl;dr: What is the reason for the existence of primitiveDropRequestFileHandle and should it still be used? Why not simply nuke it and always use primitiveDropRequestFileName + primitiveFileOpen? Looking forward to your suggestions!

Best,
Christoph

[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508
[2] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/514

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200820/80f851b7/attachment.html>


More information about the Squeak-dev mailing list