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

Vanessa Freudenberg vanessa at codefrau.net
Wed Aug 19 21:42:52 UTC 2020

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

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)


(*) 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> 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/20200819/1ede6ee7/attachment.html>

More information about the Squeak-dev mailing list