[#55222] [ruby-trunk - Feature #8468][Feedback] Remove $SAFE — "shugo (Shugo Maeda)" <redmine@...>
20 messages
2013/06/01
[#55230] [ruby-trunk - Feature #8468] Remove $SAFE
— "spatulasnout (B Kelly)" <billk@...>
2013/06/02
[#55252] [ruby-trunk - Feature #8468] Remove $SAFE
— "spatulasnout (B Kelly)" <billk@...>
2013/06/02
[#55276] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation — Tanaka Akira <akr@...>
2013/5/31 zzak <ko1@atdot.net>:
9 messages
2013/06/03
[#55278] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/03
[#55285] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Zachary Scott <zachary@...>
2013/06/04
The original wording was:
[#55288] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/04
[#55289] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Zachary Scott <zachary@...>
2013/06/04
I fail to see the difference, please provide a patch to make it more clear.
[#55290] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/04
[#55291] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Tanaka Akira <akr@...>
2013/06/04
2013/6/4 David MacMahon <davidm@astro.berkeley.edu>:
[#55297] [ruby-trunk - Bug #8486][Open] Random segmentation fault — "manudwarf (Emmanuel Bourgerie)" <manu.dwarf@...>
4 messages
2013/06/04
[#55305] [ruby-trunk - Bug #8489][Open] Tracepoint API: B_RETURN_EVENT not triggered when "next" used — deivid (David Rodríguez) <deivid.rodriguez@...>
7 messages
2013/06/04
[#55312] [ruby-trunk - Bug #8495][Open] include/ruby/win32.h assumes that __STRICT_ANSI__ isn’t set — "now (Nikolai Weibull)" <now@...>
4 messages
2013/06/05
[#55330] [ruby-trunk - Feature #8499][Assigned] Importing Hash#slice, Hash#slice!, Hash#except, and Hash#except! from ActiveSupport — "mrkn (Kenta Murata)" <muraken@...>
30 messages
2013/06/06
[#55416] CI failures: Test IO and cleanup failures — Luis Lavena <luislavena@...>
Hello,
3 messages
2013/06/10
[#55528] [ruby-trunk - Bug #8538][Open] c method not pushed into the callstack when called, but popped when returned — deivid (David Rodríguez) <deivid.rodriguez@...>
9 messages
2013/06/17
[#55530] [ruby-trunk - Feature #8539][Open] Unbundle ext/tk — "naruse (Yui NARUSE)" <naruse@...>
10 messages
2013/06/17
[#55557] [ruby-trunk - misc #8543][Open] rb_iseq_load — "alvoskov (Alexey Voskov)" <alvoskov@...>
47 messages
2013/06/19
[#65574] [ruby-trunk - Feature #8543] rb_iseq_load
— billk@...
2014/10/09
Issue #8543 has been updated by B Kelly.
[#55578] [ruby-trunk - Feature #8553][Open] Bignum#size (and Fixnum#size) — "akr (Akira Tanaka)" <akr@...>
6 messages
2013/06/21
[#55580] [CommonRuby - Feature #8556][Open] MutexedDelegator as a trivial way to make an object thread-safe — "headius (Charles Nutter)" <headius@...>
19 messages
2013/06/21
[#55590] [ruby-trunk - Bug #8560][Open] CSV, skip_lines option causes error when passing a string — "kstevens715 (Kyle Stevens)" <kstevens715@...>
5 messages
2013/06/22
[#55638] [CommonRuby - Feature #8568][Open] Introduce RbConfig value for native word size, to avoid Fixnum#size use — "headius (Charles Nutter)" <headius@...>
18 messages
2013/06/24
[#55678] [ruby-trunk - Feature #8572][Open] Fiber should be a Enumerable — "mattn (Yasuhiro Matsumoto)" <mattn.jp@...>
13 messages
2013/06/28
[#55690] [ANN] Developer Meeting - 12-07-2013 at 23:00 UTC — Aaron Patterson <tenderlove@...>
Hi everyone!
7 messages
2013/06/28
[#55699] [ruby-trunk - Feature #8579][Open] Frozen string syntax — "charliesome (Charlie Somerville)" <charliesome@...>
20 messages
2013/06/29
[ruby-core:55252] [ruby-trunk - Feature #8468] Remove $SAFE
From:
"spatulasnout (B Kelly)" <billk@...>
Date:
2013-06-02 12:15:03 UTC
List:
ruby-core #55252
Issue #8468 has been updated by spatulasnout (B Kelly). spatulasnout (B Kelly) wrote: > > What I'd really like is a mechanism in ruby > that would provide a secure sandbox that could > contain completely untrusted code. To clarify: I'd say our application treats the difference between $SAFE == 4 and $SAFE <= 1 as somewhat similar to the boundary between to 'privileged mode' and 'user mode' on a CPU. The functionality on which we depend includes: - user-mode (sandboxed) code is restricted: - can't modify/extend existing classes & modules - can't perform I/O - can't modify global or thread-local variables or environment - user-mode code MAY transition to privileged-mode via a "trap" (i.e. calling a block that was compiled in a privileged context.) Now, if something like the JVM provides a more granular permission structure, that sounds potentially great. But if we could at least just begin with the most restrictive possible sandbox, and then allow a trap to a privileged context (via calling a proc compiled at a privileged level,) my hope is such a thing could be accomplished without some of the complexity attributed to current $SAFE handling: headius (Charles Nutter) wrote: > > [$SAFE] is blacklisting, which is almost impossible to do without > leaving gaps. EVery new API needs to enlist in the blacklisting, > every change needs to be aware of it, and if you don't choose the > right safe level or one piece of code isn't aware of it, you've > got a hole. It would indeed seem ideal to require, for any Ruby VM, that the default for any newly defined native extension function is to enforce requiring privileged execution -- such that the simplest path for anyone coding a ruby extension is to define functions that the VM will only execute in a privileged context. It shouldn't be that "every new API" needs to enlist in the blacklisting. Every new pure Ruby API shouldn't need to do anything; it's either being executed in a privileged context or it isn't. It's only the native extensions that need to be specially attended to; and if they can default to requiring privileged execution unless explicitly marked as sandbox-safe by the author, then it seems to me we'd be in pretty good shape? Regards, Bill ---------------------------------------- Feature #8468: Remove $SAFE https://bugs.ruby-lang.org/issues/8468#change-39646 Author: shugo (Shugo Maeda) Status: Feedback Priority: Normal Assignee: shugo (Shugo Maeda) Category: core Target version: current: 2.1.0 Yesterday, at GitHub Tokyo drinkup (thanks, GitHub!), Matz agreed to remove the $SAFE == 4 feature from Ruby 2.1. Shibata-san, a developer of tDiary, which is the only application using $SAFE == 4, also agreed to remove it, so today is a good day to say goodbye to $SAFE (at least level 4). Furthermore, I'm wondering whether $SAFE should be removed entirely, or not. Is there anyone using $SAFE? -- http://bugs.ruby-lang.org/