[PATCH]Remove security framework

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH]Remove security framework

Gwenaël Casaccio
Hi,

Here is a patch that removes the security framework from the vm side
and the smalltalk side. It needs a review before applying.

Gwen


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

remove_security.patch (46K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH]Remove security framework

Holger Freyther
On Sun, Jan 13, 2013 at 01:18:31AM +0100, Gwenaël Casaccio wrote:
> Hi,
>
> Here is a patch that removes the security framework from the vm side
> and the smalltalk side. It needs a review before applying.

What are the arguments to remove this code from the kernel/ and from
the vm/? Is the code in the vm hard to maintain? is the framework broken?
or is the policy framework just outdated?

> -  p.untrustedContext = IS_OOP_UNTRUSTED (_gst_this_context_oop);
> +  p.untrustedContext = false;

What is the reason to leave the untrustedContext around?

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH]Remove security framework

Paolo Bonzini-2
Il 13/01/2013 08:56, Holger Hans Peter Freyther ha scritto:
>> >
>> > Here is a patch that removes the security framework from the vm side
>> > and the smalltalk side. It needs a review before applying.
> What are the arguments to remove this code from the kernel/ and from
> the vm/? Is the code in the vm hard to maintain? is the framework broken?
> or is the policy framework just outdated?

The main problem is that it was never used in practice.  There never
were any attempts to actually add permission checks to the kernel.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH]Remove security framework

Gwenaël Casaccio
In reply to this post by Holger Freyther
On 13/01/2013 08:56, Holger Hans Peter Freyther wrote:
> On Sun, Jan 13, 2013 at 01:18:31AM +0100, Gwenaël Casaccio wrote:
>> Hi,
>>
>> Here is a patch that removes the security framework from the vm side
>> and the smalltalk side. It needs a review before applying.
> What are the arguments to remove this code from the kernel/ and from
> the vm/? Is the code in the vm hard to maintain? is the framework broken?
> or is the policy framework just outdated?

Security in object based languages should be based on the capability
model (http://en.wikipedia.org/wiki/Object-capability_model 
http://en.wikipedia.org/wiki/Capability-based_security).
And as Paolo says it was never really used.

If I need security in Smalltalk, I would implement something like the e
language model.
It's more "smalltalkish", no global authority, just message sending. And
a better security
model also imply a better modular kernel, better module system,
compiler, ...

>> -  p.untrustedContext = IS_OOP_UNTRUSTED (_gst_this_context_oop);
>> +  p.untrustedContext = false;
> What is the reason to leave the untrustedContext around?

Thanks I will remove it

> _______________________________________________
> help-smalltalk mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/help-smalltalk


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH]Remove security framework

Holger Freyther
On Sun, Jan 13, 2013 at 12:34:26PM +0100, Gwenaël Casaccio wrote:


Hi,

> And as Paolo says it was never really used.

well, that is a good reason. There is no reason to have a half done
security framework.

> >>-  p.untrustedContext = IS_OOP_UNTRUSTED (_gst_this_context_oop);
> >>+  p.untrustedContext = false;
> >What is the reason to leave the untrustedContext around?
>
> Thanks I will remove it

thanks. What would be very nice is to have something like sunspider for
GST. A set of tests/examples that we want to optimize for (because I am
biased it would be the GSM parsing and formating code I have) and run
the benchmark after any libgst/ and kernel/ change.

holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH]Remove security framework

Gwenaël Casaccio
On 13/01/2013 13:19, Holger Hans Peter Freyther wrote:

> On Sun, Jan 13, 2013 at 12:34:26PM +0100, Gwenaël Casaccio wrote:
>
>
> Hi,
>
>> And as Paolo says it was never really used.
> well, that is a good reason. There is no reason to have a half done
> security framework.
>
>>>> -  p.untrustedContext = IS_OOP_UNTRUSTED (_gst_this_context_oop);
>>>> +  p.untrustedContext = false;
>>> What is the reason to leave the untrustedContext around?
>> Thanks I will remove it
> thanks. What would be very nice is to have something like sunspider for
> GST. A set of tests/examples that we want to optimize for (because I am
> biased it would be the GSM parsing and formating code I have) and run
> the benchmark after any libgst/ and kernel/ change.
>
> holger
>
> _______________________________________________
> help-smalltalk mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/help-smalltalk
Here is a new version

Gwen


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

remove_security.patch (53K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH]Remove security framework

Holger Freyther
On Mon, Jan 14, 2013 at 12:55:09PM +0100, Gwenaël Casaccio wrote:

Hi,

we have a 'pull request'[1] on github. It has been tested (32bit) by
the travis-ci system and from what I see it is ready to be merged to
master. Any objections?

holger


[1] https://github.com/gnu-smalltalk/smalltalk/pull/7

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk