access control implementation

[Philipp Tessenow]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I am still looking into implementing access control for newspeak.
After some initial hiccups, some progress can be seen.

I forked the newspeak and nsboot repositories to implement the access
control changes there. Changes made in newspeaklanguage/newspeak
and in newspeaklanguage/nsboot will be merged to stay up to date.

I've come to the assumption, that it is sufficient to implement access
control for methods (as slots are accessed via accessor methods only).
So I decided to use the bits 28/29 of the compiled method header (for
methods having the alternate bytecode set) as access control flags. I
defined the bits as in the following table:

bit 29 bit 28
0 0 unspecified
0 1 #private
1 0 #protected
1 1 #public

Bit 28 was not in use. Bit 29 was used by the VM as a "user-flag". The
accessor methods for that bit weren't called and I removed them. I still
have to figure out if and where the VM sets that bit. Does someone has
any pointer where I should search for that code?

"Visibility" setter and getter methods were added to various Mirrors,
and for CompiledMethod. The EncoderForNewspeakV4 now generates
CompiledMethods having the visibility flags set correctly. (Everything
was done for the "Squeak compilation process". I ignore
JavaScript/Dart compiling for now.)

Currently, I am working on a refactoring removing the SetterPool and
GetterPool of the Mixin class. The Setter/Getter-Pools are an
optimization to not generate getters/setters at compile time but have
them pregenerated because they are always the same methods. This,
however, changes when we have public/private/protected getter and
setter methods. The pregenerated getter/setter methods
in those pools are compiled with the old bytecodeset (with which I
cannot encode visibility). I plan to add the capability to generate a
getter/setter-method to an InstanceVariableMirror (I assume it is
appropriate, as it is in the LowLevelMirrorsForSqueak module).

The newspeak language spec does not mention access control for
classes. Gilad told me that this might be an oversight in the spec. He
will check.

When I am done with access controll for classes and the
Setter/Getter-Pool refactoring, there should
be little left to refactor in the image. Changes to the VM will
follow. I studied some of the method call and lookup code and have not
seen an obvious solution for the VM side implementation yet. If you
have any pointers, or ideas, don't hesitate to tell me :) Either way,
I will cope with that when the time comes.

Regards,
Philipp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRvsDOAAoJEOAfEteLmwSNCsQH/1Xj2DTddi0oQVjr8BOQGGUz
U8qLj6Ks8rdo/b0zjMQd2j2bn4FdqMSdYHV75Hh0qu7wwGhmk+g9yLe3R242ZiBM
u/ssXROmh0bTaK+QcaHug0kz1isJNgT7Jv9Pl6l3EXLJui5lrt171cCTyKhLJJFg
g8pFf9WZDASRhB+D8EfqOHczL6Qs9vD4sJ0/1wHE3g3E7rPxZ2JZ6DCLf+6cwLbQ
CIdF5z4+Jn/xaZrgQJy4VroQL8ZLvGsPtI4rMcMPaD3eUy8fbSgOQefDMLyzPmWK
txmo3xP6rJuTRI+M40DxjIaqpwTtHV3zo1MCWxrSakUVcHbwKPEThr8b3q6lwEU=
=7AY1
-----END PGP SIGNATURE-----

[Ryan Macnak]

On Mon, Jun 17, 2013 at 2:54 AM, Philipp Tessenow <phi...@tessenow.org> wrote:

I've come to the assumption, that it is sufficient to implement access
control for methods (as slots are accessed via accessor methods only).

Note this property also makes lazy-become easier to implement. Changing the class of an object's corpse is sufficient: the IC for each slot accessor will fail and allow patching, whereas Smalltalk's direct inst var accesses would still proceed.

 

"Visibility" setter and getter methods were added to various Mirrors,
and for CompiledMethod.

The grammar, spec and some of the existing mirrors call this property "access modifier" rather than "visibility".

 

The EncoderForNewspeakV4 now generates
CompiledMethods having the visibility flags set correctly. (Everything
was done for the "Squeak compilation process". I ignore
JavaScript/Dart compiling for now.)

I suspect enforcing access control on JavaScript/Dart will be significantly more expensive. 

The newspeak language spec does not mention access control for
classes. Gilad told me that this might be an oversight in the spec. He
will check.

Class headers can start with an access modifier, which applies to the class accessor. Primary factories are always public. This might be missing from the spec.

 

When I am done with access controll for classes and the
Setter/Getter-Pool refactoring, there should
be little left to refactor in the image. Changes to the VM will
follow. I studied some of the method call and lookup code and have not
seen an obvious solution for the VM side implementation yet.

I think we still need to add absent receiver self and outer sends, as these can access more methods than the normal sends they currently translate to.

Since access control is per object rather than per class, it will probably also affect the inline caching.

[Philipp Tessenow]

 

"Visibility" setter and getter methods were added to various Mirrors,
and for CompiledMethod.

The grammar, spec and some of the existing mirrors call this property "access modifier" rather than "visibility".

I'll rename 'visibility' to 'accessModifier'.  visibility seemed to be appropriate for me, probably because English is not my first language :)

 

The newspeak language spec does not mention access control for
classes. Gilad told me that this might be an oversight in the spec. He
will check.

Class headers can start with an access modifier, which applies to the class accessor. Primary factories are always public. This might be missing from the spec.

This (except for changing the spec) is on my ToDo list now.
 

 

When I am done with access controll for classes and the
Setter/Getter-Pool refactoring, there should
be little left to refactor in the image. Changes to the VM will
follow. I studied some of the method call and lookup code and have not
seen an obvious solution for the VM side implementation yet.

I think we still need to add absent receiver self and outer sends, as these can access more methods than the normal sends they currently translate to.

Since access control is per object rather than per class, it will probably also affect the inline caching.

Good to know. Especially the inline-caching could have given me some headache.

Thanks,
Philipp

[Gilad Bracha]

On Thursday, June 27, 2013 6:48:27 AM UTC-7, Philipp Tessenow wrote:

 

"Visibility" setter and getter methods were added to various Mirrors,
and for CompiledMethod.

The grammar, spec and some of the existing mirrors call this property "access modifier" rather than "visibility".

I'll rename 'visibility' to 'accessModifier'.  visibility seemed to be appropriate for me, probably because English is not my first language :)

It is a common confusion for native speakers as well. Something is visible if it can be seen - for example, if it is in scope. Something is accessible if it can be reached. So a member might be visible but it would still be forbidden to use it due to privacy rules.  In fact, in Newspeak, anything that is private cannot be seen - otherwise adding or removing private members would have impact on clients. Nevertheless we adhere to the more precise terminology.

 

The newspeak language spec does not mention access control for
classes. Gilad told me that this might be an oversight in the spec. He
will check.

Class headers can start with an access modifier, which applies to the class accessor. Primary factories are always public. This might be missing from the spec.

This (except for changing the spec) is on my ToDo list now.

Just in case this was at all unclear: access modifiers are specified for methods, slots and nested classes. All members are accessed via methods in any event.  Perhaps the wording in the spec could be made clearer, but there really is no issue as it stands.