[squeak-dev] What is primitiveDropRequestFileHandle and do we really need it?
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)
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
> *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!
>  https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508
>  https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/514
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev