REBOL3 tracker
  0.9.12 beta
Ticket #0001881 User: anonymous

Project:



rss
TypeWish Statusreviewed Date3-May-2011 08:04
Versionalpha 111 CategoryNative Submitted byLadislav
PlatformAll Severityminor Prioritynormal

Summary DO PATH behaviour
Description I asked REBOL users what did they prefer as the result of the example code below.

All of them preferred to get the "OK" string like in R2, with only one exception, Brian Hawley preferring to obtain the a/b path.

Reasons for the preference were:

* the users prefer the DO function to treat paths the same way as they are treated when DO encounters them inline in a code block

* the users think that for the alternative behaviour it is not needed to use the DO function

* some of the users think the current R3 behaviour is a bug

* the users find the R2 behaviour when processing the example code perfect and more logical
Example code
a: make object! [b: does ["OK"]]
a/b ; == "OK"
do 'a/b

Assigned ton/a Fixed in- Last Update6-Jan-2016 14:36


Comments
(0003171)
BrianH
3-May-2011 12:22

See the comment to #1882 for the problems with this proposal. For paths, R2 is not quite as bad, since R2's DO of a path that would evaluate to a block doesn't DO the block as well.

; In R2:
>> a: reduce [does [print "pwned!"]]
== [func [][print "pwned!"]]
>> do first [a/1]
pwned!
; The function is executed

>> a: reduce [func [:x y] [set :x :y insert clear :y "bye-bye data!" print "pwned!"]]
== [func [:x y] [set :x :y insert clear :y "bye-bye data!" print "pwned!"]]
>> do first [a/1] b: [valuable data]
** Script Error: 1 is missing its x argument
** Near: a/1
; At least you can't do get-word hacking, thank goodness, so it's no more unsafe to DO than a block or paren

>> a: [[print "pwned!"]]
== [[print "pwned!"]]
>> do first [a/1]
== [print "pwned!"] ; The block is not executed, just returned safely
(0003172)
Ladislav
3-May-2011 13:24

I did not want to discuss unrelated issues here. Please, let me know if the summary does not suffice to explain the subject of the ticket in an understandable way.
(0003182)
BrianH
5-May-2011 13:27

In the case of R2's behavior of of DO of a path!, the limitations it has can be considered to be benefits from a security standpoint.

When you are calling function values - either passed in as parameters, retrieved from data structures, whatever - you don't necessarily know how many arguments they take, even if you know they are functions at all. Calling a function that takes an unknown number of arguments the regular way, or with DO of its value, can expose the code after the point of call for maliciously crafted functions. This makes it possible to attack a function and get access to information that would otherwise be hidden, or in some cases make changes to its code. In order to reduce the attack surface of a function's code, calls to provided function values are put in parens, or at the end of a code block, or done with APPLY.

You don't have to reduce the attack surface with these tricks if you are doing blocks or parens (or any other non-function datatype), since they can't take parameters. This lack of parameter taking makes it much easier to write safe code that uses DO with these types. Making safe code easier to write is a real security advantage.

If we do this proposal, explicit DO of a path! value may or may not execute a function, depending on whether one is assigned. Since paths (and words, see #1882) are commonly used as regular data, this means that someone can cause you to execute code by slipping a bound word into your data and assigning it a function value. Without two levels of screening - the type of the value, and the type of the value assigned to it - you have to assume that DO will execute code; function values only need one level of screening. However, if that DO call can't take parameters, at least the code at the point of the call is safe, same as calling a block or paren. This reduces the attack surface of a function pretty well.

This is why the script error triggered in my previous code example is a good thing, and we should carry over that restriction to R3 if we do this proposal. If we really want to pass a properly screened function value parameters, we can use APPLY GET or DO GET instead. The explicit GET would serve as a nice warning to people reading the code, trying to debug it.
(0004272)
BrianH
27-Feb-2014 20:43

Note: I am working on an implementation of this and #1882, with this behavior:
>> do :some-word-or-path-value
be treated the same as this:
>> do reduce [:some-word-or-path-value]

Coming soon.
(0004683)
Ladislav
6-Jan-2016 14:36

No need, that is just another crippling, not worth considering.

Date User Field Action Change
6-Jan-2016 14:36 Ladislav Comment : 0004683 Added -
6-Jan-2016 06:27 Ladislav Description Modified -
5-Mar-2014 09:15 BrianH Status Modified submitted => reviewed
5-Mar-2014 09:15 BrianH Category Modified Unspecified => Native
27-Feb-2014 20:49 BrianH Comment : 0004272 Modified -
27-Feb-2014 20:43 BrianH Comment : 0004272 Added -
5-May-2011 13:29 BrianH Comment : 0003182 Modified -
5-May-2011 13:28 BrianH Comment : 0003182 Modified -
5-May-2011 13:27 BrianH Comment : 0003182 Added -
5-May-2011 12:56 BrianH Comment : 0003176 Removed -
3-May-2011 14:19 Ladislav Description Modified -
3-May-2011 14:19 Ladislav Code Modified -
3-May-2011 14:16 Ladislav Comment : 0003172 Modified -
3-May-2011 13:49 BrianH Comment : 0003176 Modified -
3-May-2011 13:48 BrianH Comment : 0003176 Added -
3-May-2011 13:37 Ladislav Comment : 0003172 Modified -
3-May-2011 13:36 Ladislav Comment : 0003172 Modified -
3-May-2011 13:36 Ladislav Comment : 0003172 Modified -
3-May-2011 13:29 Ladislav Comment : 0003172 Modified -
3-May-2011 13:24 Ladislav Comment : 0003172 Added -
3-May-2011 12:51 BrianH Comment : 0003171 Modified -
3-May-2011 12:22 BrianH Comment : 0003171 Added -
3-May-2011 08:04 Ladislav Ticket Added -