New user can't access GLASS & other classes

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

New user can't access GLASS & other classes

GLASS mailing list
Hello,

this pertains to GsDevKit with GS 3.4.1.

In a fresh client (tode1) I have created a new UserGroup (JKTestGroup), added a new UserProfile (JKTestUser) to it. Committed the transaction. I copied the content of my devKit_34 session profile and changed only the credentials. I have created a new client (tode2), in which I can see the two session profiles (devKit_34 and jkTest_34). I can log in to the stone (which is running on another host but that’s not a problem - I have ssh port forwarding set up and it works for both tode1 and tode2 clients). But when I do the ‘Test Login’ to jkTest_34 session, I get

Stone            : !@localhost#server!devKit_34
Stone host       : orion.local
GemStone version : 3.4.1
cpu kind         : x86_64
GLASS not installed
GLASS1 not installed
Tode not installed

whereas when I use the original devKit_34 session, I get the expected

Stone            : !@localhost#server!devKit_34
Stone host       : orion.local
GemStone version : 3.4.1
cpu kind         : x86_64
GLASS version    : >=1.0-beta.9.2.1 [ConfigurationOfGLASS]
Metacello version: >=1.0-beta.32.3 [ConfigurationOfMetacello]
GLASS1:
       repository: /gemstone/GsDevKit_home/shared/repos/glass/repository
Tode:
       repository: /gemstone/GsDevKit_home/shared/repos/tode/repository

I have tracked this to the UserGlobals in the DataCurator user profile having all the GLASS & Tode classes. I’ve tried several different ways to put them into the JKTestUser symbol dictionaries (insert a new one, or put the classes in the Published dictionary), but when I do that, I get an error ‘improper store’ with some parameters.

What should be a proper way to make the GLASS & Tode classes available to users other than DataCurator? Obviously I would like to do my development as a different user...

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New user can't access GLASS & other classes

GLASS mailing list
Some follow-up on the issue. I would like to extend my thanks to Richard Sargent who provided some useful tips in a private thread.

It turns out that "GLASS is designed to store code in DataCurator's UserGlobals. So everything loaded by Metacello would be loaded there.” I’ve tried several ways to get around it to be able to develop as a user other than DataCurator, unsuccessfully. Here are some of the things:

  1. I created JKTestGroup and JKTestUser. I made JKTestUser a member of all the predefined groups to make sure group membership itself is not an issue (in a real world scenario this would probably qualify as a bad practice).
  2. Then I did something that I was pretty sure was not going to be kosher (I was right) and it wouldn’t work (I was partially wrong):

    jkTestUser := AllUsers userWithId: 'JKTestUser’.
    jkUserGlobals := jkTestUser symbolList resolveSymbol: 'UserGlobals’.
    jkTestUser removeDictionaryAt: 1. “JKTestUser’s UserGlobals”
    jkTestUser insertDictionary: UserGlobals at: 1. “DataCurator’s UserGlobals”
    System commitTransaction.

    This allowed me to login as JKTestUser to a new session, and get the same info in the testLogin window as the DataCurator session. However, when I tried to do anything with the UserGlobals inserted into the test user symbol list, I started getting security violations. This was kind of expected as I didn’t think that sharing UserGlobals this way would be appropriate anyway, for several reasons. I just wanted to see if it was possible to bypass GS security by messing with the dictionaries this way. Apparently not :)
    I managed to get back the original UserGlobals into JKTestUser.

  3. I did a couple of variations on the above, e.g., directly copy classes from DataCurator’s UserGlobals dictionary to JKTestUser’s, each of the experiments would lead to a different kind of problems but security violations seem to be the most common.

  4. In my last experiment, I logged to my devKit stone with the topaz command line tool as JKTestUser and tried to input a .tpz file that I found GsDevKit uses to boostrap GLASS. The idea was that JKTestUser’s UserGlobals would have its own class hierarchy for GLASS etc. That didn’t work either, failed with compilation errors.


I understand GsDevKit is more ‘community’ oriented with large parts of the code base ported from Pharo/Seaside, and not really part of the GemStone/S product, so naturally there will be some limitations and possibly friction points. This probably has something to do with Pharo/Seaside being essentially a single user system. However, I really dislike the idea of developing as DataCurator, so I am thinking that I would create some abstract classes and new ‘globals’ in the Published dictionary pointing to GLASS stuff. That might provide access to the things that I need as a ‘developer’ user. Naturally, the tricky part here will be to get a useable IDE working. Tode will only work with the bootstrapped GLASS, so it’s a bit of a chicken and egg situation.

I wonder if others have similar experiences, or if people just use DataCurator as the default user when developing with GLASS. Or, if it is possible to bootstrap GLASS into a stone for a user other than DataCurator, what’s the trick?

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 03-07-2018, at 10:28 PM, Jerry Kott <[hidden email]> wrote:

Hello,

this pertains to GsDevKit with GS 3.4.1.

In a fresh client (tode1) I have created a new UserGroup (JKTestGroup), added a new UserProfile (JKTestUser) to it. Committed the transaction. I copied the content of my devKit_34 session profile and changed only the credentials. I have created a new client (tode2), in which I can see the two session profiles (devKit_34 and jkTest_34). I can log in to the stone (which is running on another host but that’s not a problem - I have ssh port forwarding set up and it works for both tode1 and tode2 clients). But when I do the ‘Test Login’ to jkTest_34 session, I get

Stone            : !@localhost#server!devKit_34
Stone host       : orion.local
GemStone version : 3.4.1
cpu kind         : x86_64
GLASS not installed
GLASS1 not installed
Tode not installed

whereas when I use the original devKit_34 session, I get the expected

Stone            : !@localhost#server!devKit_34
Stone host       : orion.local
GemStone version : 3.4.1
cpu kind         : x86_64
GLASS version    : >=1.0-beta.9.2.1 [ConfigurationOfGLASS]
Metacello version: >=1.0-beta.32.3 [ConfigurationOfMetacello]
GLASS1:
       repository: /gemstone/GsDevKit_home/shared/repos/glass/repository
Tode:
       repository: /gemstone/GsDevKit_home/shared/repos/tode/repository

I have tracked this to the UserGlobals in the DataCurator user profile having all the GLASS & Tode classes. I’ve tried several different ways to put them into the JKTestUser symbol dictionaries (insert a new one, or put the classes in the Published dictionary), but when I do that, I get an error ‘improper store’ with some parameters.

What should be a proper way to make the GLASS & Tode classes available to users other than DataCurator? Obviously I would like to do my development as a different user...

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5





_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New user can't access GLASS & other classes

GLASS mailing list
Jerry,

I agree that it would be nice if the technology did not dictate a particular usage pattern, and I appreciate your recognition that there are a variety of factors involved in the community/open source project. Not as a way to convince you to do something else, but as a way for me to better understand people’s use of the system, I’d like to understand why you “really dislike the idea of developing as DataCurator”. While you are right that it doesn’t make sense to think of GemStone as a “single-user system” in a production sense, I wonder if it does make sense to think of it that way for development. Even for production, might it be best to think of it as a “single-application system” such that letting DataCurator own the application (as SystemUser owns the system)? What are your issues with DataCurator?

James

On Jul 9, 2018, at 1:27 PM, Jerry Kott via Glass <[hidden email]> wrote:

Some follow-up on the issue. I would like to extend my thanks to Richard Sargent who provided some useful tips in a private thread.

It turns out that "GLASS is designed to store code in DataCurator's UserGlobals. So everything loaded by Metacello would be loaded there.” I’ve tried several ways to get around it to be able to develop as a user other than DataCurator, unsuccessfully. Here are some of the things:

  1. I created JKTestGroup and JKTestUser. I made JKTestUser a member of all the predefined groups to make sure group membership itself is not an issue (in a real world scenario this would probably qualify as a bad practice).
  2. Then I did something that I was pretty sure was not going to be kosher (I was right) and it wouldn’t work (I was partially wrong):

    jkTestUser := AllUsers userWithId: 'JKTestUser’.
    jkUserGlobals := jkTestUser symbolList resolveSymbol: 'UserGlobals’.
    jkTestUser removeDictionaryAt: 1. “JKTestUser’s UserGlobals”
    jkTestUser insertDictionary: UserGlobals at: 1. “DataCurator’s UserGlobals”
    System commitTransaction.

    This allowed me to login as JKTestUser to a new session, and get the same info in the testLogin window as the DataCurator session. However, when I tried to do anything with the UserGlobals inserted into the test user symbol list, I started getting security violations. This was kind of expected as I didn’t think that sharing UserGlobals this way would be appropriate anyway, for several reasons. I just wanted to see if it was possible to bypass GS security by messing with the dictionaries this way. Apparently not :)
    I managed to get back the original UserGlobals into JKTestUser.

  3. I did a couple of variations on the above, e.g., directly copy classes from DataCurator’s UserGlobals dictionary to JKTestUser’s, each of the experiments would lead to a different kind of problems but security violations seem to be the most common.

  4. In my last experiment, I logged to my devKit stone with the topaz command line tool as JKTestUser and tried to input a .tpz file that I found GsDevKit uses to boostrap GLASS. The idea was that JKTestUser’s UserGlobals would have its own class hierarchy for GLASS etc. That didn’t work either, failed with compilation errors.


I understand GsDevKit is more ‘community’ oriented with large parts of the code base ported from Pharo/Seaside, and not really part of the GemStone/S product, so naturally there will be some limitations and possibly friction points. This probably has something to do with Pharo/Seaside being essentially a single user system. However, I really dislike the idea of developing as DataCurator, so I am thinking that I would create some abstract classes and new ‘globals’ in the Published dictionary pointing to GLASS stuff. That might provide access to the things that I need as a ‘developer’ user. Naturally, the tricky part here will be to get a useable IDE working. Tode will only work with the bootstrapped GLASS, so it’s a bit of a chicken and egg situation.

I wonder if others have similar experiences, or if people just use DataCurator as the default user when developing with GLASS. Or, if it is possible to bootstrap GLASS into a stone for a user other than DataCurator, what’s the trick?

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 03-07-2018, at 10:28 PM, Jerry Kott <[hidden email]> wrote:

Hello,

this pertains to GsDevKit with GS 3.4.1.

In a fresh client (tode1) I have created a new UserGroup (JKTestGroup), added a new UserProfile (JKTestUser) to it. Committed the transaction. I copied the content of my devKit_34 session profile and changed only the credentials. I have created a new client (tode2), in which I can see the two session profiles (devKit_34 and jkTest_34). I can log in to the stone (which is running on another host but that’s not a problem - I have ssh port forwarding set up and it works for both tode1 and tode2 clients). But when I do the ‘Test Login’ to jkTest_34 session, I get

Stone            : !@localhost#server!devKit_34
Stone host       : orion.local
GemStone version : 3.4.1
cpu kind         : x86_64
GLASS not installed
GLASS1 not installed
Tode not installed

whereas when I use the original devKit_34 session, I get the expected

Stone            : !@localhost#server!devKit_34
Stone host       : orion.local
GemStone version : 3.4.1
cpu kind         : x86_64
GLASS version    : >=1.0-beta.9.2.1 [ConfigurationOfGLASS]
Metacello version: >=1.0-beta.32.3 [ConfigurationOfMetacello]
GLASS1:
       repository: /gemstone/GsDevKit_home/shared/repos/glass/repository
Tode:
       repository: /gemstone/GsDevKit_home/shared/repos/tode/repository

I have tracked this to the UserGlobals in the DataCurator user profile having all the GLASS & Tode classes. I’ve tried several different ways to put them into the JKTestUser symbol dictionaries (insert a new one, or put the classes in the Published dictionary), but when I do that, I get an error ‘improper store’ with some parameters.

What should be a proper way to make the GLASS & Tode classes available to users other than DataCurator? Obviously I would like to do my development as a different user...

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: New user can't access GLASS & other classes

GLASS mailing list
In reply to this post by GLASS mailing list
Jerry,

It has been several years since I've worked around issues like that, so sorry if my recollection is fuzzy. You can share variables across different users. It looks like segmenting and then permissions configuration are missing. Be aware that the UserGlobals SymbolDictionary is (or perhaps was) an Association-based collection and so reference the association instance of a variable rather than the referencing the value. 

If you somehow still have troubles then review which users get to update the variable and perhaps store some data within your own data structure. Though hard to explain all the code management advantages right now, a strategy I found best was to have a shared application global that held a singleton instance of an AppRoot kind of class. Application code would reference the instance through the global by behavior, and instance migration was useful to have. Practical implication is you only need to solve this global sharing for one variable. Of course you can always use a class instance variable to access by way of code like "AppRoot singleton". The code then binds to a more customary class than a global variable. There are several tricks that can be useful.

Background was that I wrote all the GemKit code management to manage user-specific code and also to apply user-specific patches. Many good tricks we're in that code base. Perhaps Montecello could borrow from tricks that we're found in GemKit. 

I understand that you'll be looking for the simplest workaround for GLASS, and that several of the tricks mentioned above aren't customarily for your refactoring. The association and permissions may be a good start. I recall the GS manuals gave examples that accessed the association instances for sharing between UserGlobals.

Hope this helps.

Paul Baumann
Retired young and loving it



On Mon, Jul 9, 2018, 4:27 PM Jerry Kott via Glass <[hidden email]> wrote:
Some follow-up on the issue. I would like to extend my thanks to Richard Sargent who provided some useful tips in a private thread.

It turns out that "GLASS is designed to store code in DataCurator's UserGlobals. So everything loaded by Metacello would be loaded there.” I’ve tried several ways to get around it to be able to develop as a user other than DataCurator, unsuccessfully. Here are some of the things:

  1. I created JKTestGroup and JKTestUser. I made JKTestUser a member of all the predefined groups to make sure group membership itself is not an issue (in a real world scenario this would probably qualify as a bad practice).
  2. Then I did something that I was pretty sure was not going to be kosher (I was right) and it wouldn’t work (I was partially wrong):

    jkTestUser := AllUsers userWithId: 'JKTestUser’.
    jkUserGlobals := jkTestUser symbolList resolveSymbol: 'UserGlobals’.
    jkTestUser removeDictionaryAt: 1. “JKTestUser’s UserGlobals”
    jkTestUser insertDictionary: UserGlobals at: 1. “DataCurator’s UserGlobals”
    System commitTransaction.

    This allowed me to login as JKTestUser to a new session, and get the same info in the testLogin window as the DataCurator session. However, when I tried to do anything with the UserGlobals inserted into the test user symbol list, I started getting security violations. This was kind of expected as I didn’t think that sharing UserGlobals this way would be appropriate anyway, for several reasons. I just wanted to see if it was possible to bypass GS security by messing with the dictionaries this way. Apparently not :)
    I managed to get back the original UserGlobals into JKTestUser.

  3. I did a couple of variations on the above, e.g., directly copy classes from DataCurator’s UserGlobals dictionary to JKTestUser’s, each of the experiments would lead to a different kind of problems but security violations seem to be the most common.

  4. In my last experiment, I logged to my devKit stone with the topaz command line tool as JKTestUser and tried to input a .tpz file that I found GsDevKit uses to boostrap GLASS. The idea was that JKTestUser’s UserGlobals would have its own class hierarchy for GLASS etc. That didn’t work either, failed with compilation errors.


I understand GsDevKit is more ‘community’ oriented with large parts of the code base ported from Pharo/Seaside, and not really part of the GemStone/S product, so naturally there will be some limitations and possibly friction points. This probably has something to do with Pharo/Seaside being essentially a single user system. However, I really dislike the idea of developing as DataCurator, so I am thinking that I would create some abstract classes and new ‘globals’ in the Published dictionary pointing to GLASS stuff. That might provide access to the things that I need as a ‘developer’ user. Naturally, the tricky part here will be to get a useable IDE working. Tode will only work with the bootstrapped GLASS, so it’s a bit of a chicken and egg situation.

I wonder if others have similar experiences, or if people just use DataCurator as the default user when developing with GLASS. Or, if it is possible to bootstrap GLASS into a stone for a user other than DataCurator, what’s the trick?

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 03-07-2018, at 10:28 PM, Jerry Kott <[hidden email]> wrote:

Hello,

this pertains to GsDevKit with GS 3.4.1.

In a fresh client (tode1) I have created a new UserGroup (JKTestGroup), added a new UserProfile (JKTestUser) to it. Committed the transaction. I copied the content of my devKit_34 session profile and changed only the credentials. I have created a new client (tode2), in which I can see the two session profiles (devKit_34 and jkTest_34). I can log in to the stone (which is running on another host but that’s not a problem - I have ssh port forwarding set up and it works for both tode1 and tode2 clients). But when I do the ‘Test Login’ to jkTest_34 session, I get

Stone            : !@localhost#server!devKit_34
Stone host       : orion.local
GemStone version : 3.4.1
cpu kind         : x86_64
GLASS not installed
GLASS1 not installed
Tode not installed

whereas when I use the original devKit_34 session, I get the expected

Stone            : !@localhost#server!devKit_34
Stone host       : orion.local
GemStone version : 3.4.1
cpu kind         : x86_64
GLASS version    : >=1.0-beta.9.2.1 [ConfigurationOfGLASS]
Metacello version: >=1.0-beta.32.3 [ConfigurationOfMetacello]
GLASS1:
       repository: /gemstone/GsDevKit_home/shared/repos/glass/repository
Tode:
       repository: /gemstone/GsDevKit_home/shared/repos/tode/repository

I have tracked this to the UserGlobals in the DataCurator user profile having all the GLASS & Tode classes. I’ve tried several different ways to put them into the JKTestUser symbol dictionaries (insert a new one, or put the classes in the Published dictionary), but when I do that, I get an error ‘improper store’ with some parameters.

What should be a proper way to make the GLASS & Tode classes available to users other than DataCurator? Obviously I would like to do my development as a different user...

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: New user can't access GLASS & other classes

GLASS mailing list
In reply to this post by GLASS mailing list
Thanks for your reply, James.

Part of this is because of circumstances that were not my own choice. I have become somewhat of a security freak, and professional paranoia has become my SOP. I think of DataCurator as a privileged user (not quite like ‘root’ but close enough), as do most developers, I think. On a multi-developer team, I believe it’s essential to maintain code ownership, and using shared credentials of any kind (DataCurator or something else) makes that impossible. I would actually argue that letting DataCurator own the application on a production system (or another user with similar elevated privilege) is more appropriate than using it for development. I am sure this will depend on the context, such as the dynamics and the size of the development team, but from security perspective that’s what I would like to have.

At this moment, I am a single guy re-learning GemStone after 20 years of absence, so from a practical standpoint, using DataCurator for everything should be fine. But since I do want to understand the GS security model in-depth, I felt it was important for me to pretend I am on a multi-user team and only the ‘real’ data curator should be able to do certain things that other developers can not.

Cheers,

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 09-07-2018, at 1:47 PM, James Foster <[hidden email]> wrote:

Jerry,

I agree that it would be nice if the technology did not dictate a particular usage pattern, and I appreciate your recognition that there are a variety of factors involved in the community/open source project. Not as a way to convince you to do something else, but as a way for me to better understand people’s use of the system, I’d like to understand why you “really dislike the idea of developing as DataCurator”. While you are right that it doesn’t make sense to think of GemStone as a “single-user system” in a production sense, I wonder if it does make sense to think of it that way for development. Even for production, might it be best to think of it as a “single-application system” such that letting DataCurator own the application (as SystemUser owns the system)? What are your issues with DataCurator?

James

On Jul 9, 2018, at 1:27 PM, Jerry Kott via Glass <[hidden email]> wrote:

Some follow-up on the issue. I would like to extend my thanks to Richard Sargent who provided some useful tips in a private thread.

It turns out that "GLASS is designed to store code in DataCurator's UserGlobals. So everything loaded by Metacello would be loaded there.” I’ve tried several ways to get around it to be able to develop as a user other than DataCurator, unsuccessfully. Here are some of the things:

  1. I created JKTestGroup and JKTestUser. I made JKTestUser a member of all the predefined groups to make sure group membership itself is not an issue (in a real world scenario this would probably qualify as a bad practice).
  2. Then I did something that I was pretty sure was not going to be kosher (I was right) and it wouldn’t work (I was partially wrong):

    jkTestUser := AllUsers userWithId: 'JKTestUser’.
    jkUserGlobals := jkTestUser symbolList resolveSymbol: 'UserGlobals’.
    jkTestUser removeDictionaryAt: 1. “JKTestUser’s UserGlobals”
    jkTestUser insertDictionary: UserGlobals at: 1. “DataCurator’s UserGlobals”
    System commitTransaction.

    This allowed me to login as JKTestUser to a new session, and get the same info in the testLogin window as the DataCurator session. However, when I tried to do anything with the UserGlobals inserted into the test user symbol list, I started getting security violations. This was kind of expected as I didn’t think that sharing UserGlobals this way would be appropriate anyway, for several reasons. I just wanted to see if it was possible to bypass GS security by messing with the dictionaries this way. Apparently not :)
    I managed to get back the original UserGlobals into JKTestUser.

  3. I did a couple of variations on the above, e.g., directly copy classes from DataCurator’s UserGlobals dictionary to JKTestUser’s, each of the experiments would lead to a different kind of problems but security violations seem to be the most common.

  4. In my last experiment, I logged to my devKit stone with the topaz command line tool as JKTestUser and tried to input a .tpz file that I found GsDevKit uses to boostrap GLASS. The idea was that JKTestUser’s UserGlobals would have its own class hierarchy for GLASS etc. That didn’t work either, failed with compilation errors.


I understand GsDevKit is more ‘community’ oriented with large parts of the code base ported from Pharo/Seaside, and not really part of the GemStone/S product, so naturally there will be some limitations and possibly friction points. This probably has something to do with Pharo/Seaside being essentially a single user system. However, I really dislike the idea of developing as DataCurator, so I am thinking that I would create some abstract classes and new ‘globals’ in the Published dictionary pointing to GLASS stuff. That might provide access to the things that I need as a ‘developer’ user. Naturally, the tricky part here will be to get a useable IDE working. Tode will only work with the bootstrapped GLASS, so it’s a bit of a chicken and egg situation.

I wonder if others have similar experiences, or if people just use DataCurator as the default user when developing with GLASS. Or, if it is possible to bootstrap GLASS into a stone for a user other than DataCurator, what’s the trick?



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New user can't access GLASS & other classes

GLASS mailing list
Jerry,

In the old days (I started with GemStone about 20 years ago) it was common to have a single development database with multiple developers, and giving each their own login might be warranted as a security measure. Today I’d be inclined to give each developer their own repository and have them share code through an external source code management (SCM) system. With that you would maintain code ownership (through the SCM system). For those that are security conscious, it is common to have the system administrator load code into production directly from the SCM using a DataCurator password not known to the developers. If you really wanted to ensure developer isolation, you could give each developer a different repository with different passwords for DataCurator (and SystemUser). In any case, I’d be inclined to use DataCurator for development and isolate the repositories rather than the users.

James

On Jul 10, 2018, at 10:54 AM, Jerry Kott via Glass <[hidden email]> wrote:

Thanks for your reply, James.

Part of this is because of circumstances that were not my own choice. I have become somewhat of a security freak, and professional paranoia has become my SOP. I think of DataCurator as a privileged user (not quite like ‘root’ but close enough), as do most developers, I think. On a multi-developer team, I believe it’s essential to maintain code ownership, and using shared credentials of any kind (DataCurator or something else) makes that impossible. I would actually argue that letting DataCurator own the application on a production system (or another user with similar elevated privilege) is more appropriate than using it for development. I am sure this will depend on the context, such as the dynamics and the size of the development team, but from security perspective that’s what I would like to have.

At this moment, I am a single guy re-learning GemStone after 20 years of absence, so from a practical standpoint, using DataCurator for everything should be fine. But since I do want to understand the GS security model in-depth, I felt it was important for me to pretend I am on a multi-user team and only the ‘real’ data curator should be able to do certain things that other developers can not.

Cheers,

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 09-07-2018, at 1:47 PM, James Foster <[hidden email]> wrote:

Jerry,

I agree that it would be nice if the technology did not dictate a particular usage pattern, and I appreciate your recognition that there are a variety of factors involved in the community/open source project. Not as a way to convince you to do something else, but as a way for me to better understand people’s use of the system, I’d like to understand why you “really dislike the idea of developing as DataCurator”. While you are right that it doesn’t make sense to think of GemStone as a “single-user system” in a production sense, I wonder if it does make sense to think of it that way for development. Even for production, might it be best to think of it as a “single-application system” such that letting DataCurator own the application (as SystemUser owns the system)? What are your issues with DataCurator?

James

On Jul 9, 2018, at 1:27 PM, Jerry Kott via Glass <[hidden email]> wrote:

Some follow-up on the issue. I would like to extend my thanks to Richard Sargent who provided some useful tips in a private thread.

It turns out that "GLASS is designed to store code in DataCurator's UserGlobals. So everything loaded by Metacello would be loaded there.” I’ve tried several ways to get around it to be able to develop as a user other than DataCurator, unsuccessfully. Here are some of the things:

  1. I created JKTestGroup and JKTestUser. I made JKTestUser a member of all the predefined groups to make sure group membership itself is not an issue (in a real world scenario this would probably qualify as a bad practice).
  2. Then I did something that I was pretty sure was not going to be kosher (I was right) and it wouldn’t work (I was partially wrong):

    jkTestUser := AllUsers userWithId: 'JKTestUser’.
    jkUserGlobals := jkTestUser symbolList resolveSymbol: 'UserGlobals’.
    jkTestUser removeDictionaryAt: 1. “JKTestUser’s UserGlobals”
    jkTestUser insertDictionary: UserGlobals at: 1. “DataCurator’s UserGlobals”
    System commitTransaction.

    This allowed me to login as JKTestUser to a new session, and get the same info in the testLogin window as the DataCurator session. However, when I tried to do anything with the UserGlobals inserted into the test user symbol list, I started getting security violations. This was kind of expected as I didn’t think that sharing UserGlobals this way would be appropriate anyway, for several reasons. I just wanted to see if it was possible to bypass GS security by messing with the dictionaries this way. Apparently not :)
    I managed to get back the original UserGlobals into JKTestUser.

  3. I did a couple of variations on the above, e.g., directly copy classes from DataCurator’s UserGlobals dictionary to JKTestUser’s, each of the experiments would lead to a different kind of problems but security violations seem to be the most common.

  4. In my last experiment, I logged to my devKit stone with the topaz command line tool as JKTestUser and tried to input a .tpz file that I found GsDevKit uses to boostrap GLASS. The idea was that JKTestUser’s UserGlobals would have its own class hierarchy for GLASS etc. That didn’t work either, failed with compilation errors.


I understand GsDevKit is more ‘community’ oriented with large parts of the code base ported from Pharo/Seaside, and not really part of the GemStone/S product, so naturally there will be some limitations and possibly friction points. This probably has something to do with Pharo/Seaside being essentially a single user system. However, I really dislike the idea of developing as DataCurator, so I am thinking that I would create some abstract classes and new ‘globals’ in the Published dictionary pointing to GLASS stuff. That might provide access to the things that I need as a ‘developer’ user. Naturally, the tricky part here will be to get a useable IDE working. Tode will only work with the bootstrapped GLASS, so it’s a bit of a chicken and egg situation.

I wonder if others have similar experiences, or if people just use DataCurator as the default user when developing with GLASS. Or, if it is possible to bootstrap GLASS into a stone for a user other than DataCurator, what’s the trick?


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: New user can't access GLASS & other classes

GLASS mailing list
I see… that seems like a reasonable solution. Although it kind of defeats the purpose of having multiple roles in each developer’s repository (the same thing could be achieved with a single high-privilege user), I can see how it would be applicable in the mult-user development team scenario. Would it be fair to say that DataCurator is there mostly for historic reasons, at least in the development stage? I can see how it would be more actively used in a deployed production environment, though…

Out of curiosity: what are the commonly used SCM systems with GemStone? I know GsDevKit uses Metacello to some degree, how about others? Are there frameworks / libraries for direct integration? Or is it more a ‘file-out’ / ‘commit’ type of use?

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 10-07-2018, at 11:06 AM, James Foster <[hidden email]> wrote:

Jerry,

In the old days (I started with GemStone about 20 years ago) it was common to have a single development database with multiple developers, and giving each their own login might be warranted as a security measure. Today I’d be inclined to give each developer their own repository and have them share code through an external source code management (SCM) system. With that you would maintain code ownership (through the SCM system). For those that are security conscious, it is common to have the system administrator load code into production directly from the SCM using a DataCurator password not known to the developers. If you really wanted to ensure developer isolation, you could give each developer a different repository with different passwords for DataCurator (and SystemUser). In any case, I’d be inclined to use DataCurator for development and isolate the repositories rather than the users.

James

On Jul 10, 2018, at 10:54 AM, Jerry Kott via Glass <[hidden email]> wrote:

Thanks for your reply, James.

Part of this is because of circumstances that were not my own choice. I have become somewhat of a security freak, and professional paranoia has become my SOP. I think of DataCurator as a privileged user (not quite like ‘root’ but close enough), as do most developers, I think. On a multi-developer team, I believe it’s essential to maintain code ownership, and using shared credentials of any kind (DataCurator or something else) makes that impossible. I would actually argue that letting DataCurator own the application on a production system (or another user with similar elevated privilege) is more appropriate than using it for development. I am sure this will depend on the context, such as the dynamics and the size of the development team, but from security perspective that’s what I would like to have.

At this moment, I am a single guy re-learning GemStone after 20 years of absence, so from a practical standpoint, using DataCurator for everything should be fine. But since I do want to understand the GS security model in-depth, I felt it was important for me to pretend I am on a multi-user team and only the ‘real’ data curator should be able to do certain things that other developers can not.

Cheers,

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 09-07-2018, at 1:47 PM, James Foster <[hidden email]> wrote:

Jerry,

I agree that it would be nice if the technology did not dictate a particular usage pattern, and I appreciate your recognition that there are a variety of factors involved in the community/open source project. Not as a way to convince you to do something else, but as a way for me to better understand people’s use of the system, I’d like to understand why you “really dislike the idea of developing as DataCurator”. While you are right that it doesn’t make sense to think of GemStone as a “single-user system” in a production sense, I wonder if it does make sense to think of it that way for development. Even for production, might it be best to think of it as a “single-application system” such that letting DataCurator own the application (as SystemUser owns the system)? What are your issues with DataCurator?

James

On Jul 9, 2018, at 1:27 PM, Jerry Kott via Glass <[hidden email]> wrote:

Some follow-up on the issue. I would like to extend my thanks to Richard Sargent who provided some useful tips in a private thread.

It turns out that "GLASS is designed to store code in DataCurator's UserGlobals. So everything loaded by Metacello would be loaded there.” I’ve tried several ways to get around it to be able to develop as a user other than DataCurator, unsuccessfully. Here are some of the things:

  1. I created JKTestGroup and JKTestUser. I made JKTestUser a member of all the predefined groups to make sure group membership itself is not an issue (in a real world scenario this would probably qualify as a bad practice).
  2. Then I did something that I was pretty sure was not going to be kosher (I was right) and it wouldn’t work (I was partially wrong):

    jkTestUser := AllUsers userWithId: 'JKTestUser’.
    jkUserGlobals := jkTestUser symbolList resolveSymbol: 'UserGlobals’.
    jkTestUser removeDictionaryAt: 1. “JKTestUser’s UserGlobals”
    jkTestUser insertDictionary: UserGlobals at: 1. “DataCurator’s UserGlobals”
    System commitTransaction.

    This allowed me to login as JKTestUser to a new session, and get the same info in the testLogin window as the DataCurator session. However, when I tried to do anything with the UserGlobals inserted into the test user symbol list, I started getting security violations. This was kind of expected as I didn’t think that sharing UserGlobals this way would be appropriate anyway, for several reasons. I just wanted to see if it was possible to bypass GS security by messing with the dictionaries this way. Apparently not :)
    I managed to get back the original UserGlobals into JKTestUser.

  3. I did a couple of variations on the above, e.g., directly copy classes from DataCurator’s UserGlobals dictionary to JKTestUser’s, each of the experiments would lead to a different kind of problems but security violations seem to be the most common.

  4. In my last experiment, I logged to my devKit stone with the topaz command line tool as JKTestUser and tried to input a .tpz file that I found GsDevKit uses to boostrap GLASS. The idea was that JKTestUser’s UserGlobals would have its own class hierarchy for GLASS etc. That didn’t work either, failed with compilation errors.


I understand GsDevKit is more ‘community’ oriented with large parts of the code base ported from Pharo/Seaside, and not really part of the GemStone/S product, so naturally there will be some limitations and possibly friction points. This probably has something to do with Pharo/Seaside being essentially a single user system. However, I really dislike the idea of developing as DataCurator, so I am thinking that I would create some abstract classes and new ‘globals’ in the Published dictionary pointing to GLASS stuff. That might provide access to the things that I need as a ‘developer’ user. Naturally, the tricky part here will be to get a useable IDE working. Tode will only work with the bootstrapped GLASS, so it’s a bit of a chicken and egg situation.

I wonder if others have similar experiences, or if people just use DataCurator as the default user when developing with GLASS. Or, if it is possible to bootstrap GLASS into a stone for a user other than DataCurator, what’s the trick?


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass



_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New user can't access GLASS & other classes

GLASS mailing list
You are right that multiple roles might make more sense in production than in development. On the other hand, it still makes sense to separate the SystemUser (who owns the vendor-supplied kernel Globals) from the application development role. This prevents the application developer from accidentally (or intentionally) changing the core classes. One could still model different roles in development with DataCurator “owning” the application classes (placed in Published) and sample “users” who may have different application privileges and would “own” the data (perhaps in separate UserGlobal dictionaries). So, no, DataCurator is not mostly historic but provides a clear individual “developer” role (even if the developer is unnamed). Besides, while there are differences in scale and usage patterns between development and production, you wouldn’t say that transactions are only meaningful in production (even if a single developer is unlikely to have a conflict). Generally it makes sense to have the developer work in an environment modeled on production, and production won’t have multiple developer logins.

Even if you put all the developers in one database, you would probably want them to have separate copies of the code so that a halt put in by one would not be visible to another. If someone is rewriting a section then it should not be broken for others. So, while maybe you could isolate each user in the same database, why not just give each user their own database? With today’s hardware it is cheap enough. You would want to do SCM outside the repository anyway.

SCM options include (1) file-in/file-out in Topaz format (text files that can then be placed into Git or some other file-based SCM; (2) Monticello; and (3) FileTree/Tonel/Rowan (see https://github.com/dalehenrich/Rowan for more details).

James

On Jul 10, 2018, at 11:32 AM, Jerry Kott <[hidden email]> wrote:

I see… that seems like a reasonable solution. Although it kind of defeats the purpose of having multiple roles in each developer’s repository (the same thing could be achieved with a single high-privilege user), I can see how it would be applicable in the mult-user development team scenario. Would it be fair to say that DataCurator is there mostly for historic reasons, at least in the development stage? I can see how it would be more actively used in a deployed production environment, though…

Out of curiosity: what are the commonly used SCM systems with GemStone? I know GsDevKit uses Metacello to some degree, how about others? Are there frameworks / libraries for direct integration? Or is it more a ‘file-out’ / ‘commit’ type of use?

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 10-07-2018, at 11:06 AM, James Foster <[hidden email]> wrote:

Jerry,

In the old days (I started with GemStone about 20 years ago) it was common to have a single development database with multiple developers, and giving each their own login might be warranted as a security measure. Today I’d be inclined to give each developer their own repository and have them share code through an external source code management (SCM) system. With that you would maintain code ownership (through the SCM system). For those that are security conscious, it is common to have the system administrator load code into production directly from the SCM using a DataCurator password not known to the developers. If you really wanted to ensure developer isolation, you could give each developer a different repository with different passwords for DataCurator (and SystemUser). In any case, I’d be inclined to use DataCurator for development and isolate the repositories rather than the users.

James

On Jul 10, 2018, at 10:54 AM, Jerry Kott via Glass <[hidden email]> wrote:

Thanks for your reply, James.

Part of this is because of circumstances that were not my own choice. I have become somewhat of a security freak, and professional paranoia has become my SOP. I think of DataCurator as a privileged user (not quite like ‘root’ but close enough), as do most developers, I think. On a multi-developer team, I believe it’s essential to maintain code ownership, and using shared credentials of any kind (DataCurator or something else) makes that impossible. I would actually argue that letting DataCurator own the application on a production system (or another user with similar elevated privilege) is more appropriate than using it for development. I am sure this will depend on the context, such as the dynamics and the size of the development team, but from security perspective that’s what I would like to have.

At this moment, I am a single guy re-learning GemStone after 20 years of absence, so from a practical standpoint, using DataCurator for everything should be fine. But since I do want to understand the GS security model in-depth, I felt it was important for me to pretend I am on a multi-user team and only the ‘real’ data curator should be able to do certain things that other developers can not.

Cheers,

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 09-07-2018, at 1:47 PM, James Foster <[hidden email]> wrote:

Jerry,

I agree that it would be nice if the technology did not dictate a particular usage pattern, and I appreciate your recognition that there are a variety of factors involved in the community/open source project. Not as a way to convince you to do something else, but as a way for me to better understand people’s use of the system, I’d like to understand why you “really dislike the idea of developing as DataCurator”. While you are right that it doesn’t make sense to think of GemStone as a “single-user system” in a production sense, I wonder if it does make sense to think of it that way for development. Even for production, might it be best to think of it as a “single-application system” such that letting DataCurator own the application (as SystemUser owns the system)? What are your issues with DataCurator?

James

On Jul 9, 2018, at 1:27 PM, Jerry Kott via Glass <[hidden email]> wrote:

Some follow-up on the issue. I would like to extend my thanks to Richard Sargent who provided some useful tips in a private thread.

It turns out that "GLASS is designed to store code in DataCurator's UserGlobals. So everything loaded by Metacello would be loaded there.” I’ve tried several ways to get around it to be able to develop as a user other than DataCurator, unsuccessfully. Here are some of the things:

  1. I created JKTestGroup and JKTestUser. I made JKTestUser a member of all the predefined groups to make sure group membership itself is not an issue (in a real world scenario this would probably qualify as a bad practice).
  2. Then I did something that I was pretty sure was not going to be kosher (I was right) and it wouldn’t work (I was partially wrong):

    jkTestUser := AllUsers userWithId: 'JKTestUser’.
    jkUserGlobals := jkTestUser symbolList resolveSymbol: 'UserGlobals’.
    jkTestUser removeDictionaryAt: 1. “JKTestUser’s UserGlobals”
    jkTestUser insertDictionary: UserGlobals at: 1. “DataCurator’s UserGlobals”
    System commitTransaction.

    This allowed me to login as JKTestUser to a new session, and get the same info in the testLogin window as the DataCurator session. However, when I tried to do anything with the UserGlobals inserted into the test user symbol list, I started getting security violations. This was kind of expected as I didn’t think that sharing UserGlobals this way would be appropriate anyway, for several reasons. I just wanted to see if it was possible to bypass GS security by messing with the dictionaries this way. Apparently not :)
    I managed to get back the original UserGlobals into JKTestUser.

  3. I did a couple of variations on the above, e.g., directly copy classes from DataCurator’s UserGlobals dictionary to JKTestUser’s, each of the experiments would lead to a different kind of problems but security violations seem to be the most common.

  4. In my last experiment, I logged to my devKit stone with the topaz command line tool as JKTestUser and tried to input a .tpz file that I found GsDevKit uses to boostrap GLASS. The idea was that JKTestUser’s UserGlobals would have its own class hierarchy for GLASS etc. That didn’t work either, failed with compilation errors.


I understand GsDevKit is more ‘community’ oriented with large parts of the code base ported from Pharo/Seaside, and not really part of the GemStone/S product, so naturally there will be some limitations and possibly friction points. This probably has something to do with Pharo/Seaside being essentially a single user system. However, I really dislike the idea of developing as DataCurator, so I am thinking that I would create some abstract classes and new ‘globals’ in the Published dictionary pointing to GLASS stuff. That might provide access to the things that I need as a ‘developer’ user. Naturally, the tricky part here will be to get a useable IDE working. Tode will only work with the bootstrapped GLASS, so it’s a bit of a chicken and egg situation.

I wonder if others have similar experiences, or if people just use DataCurator as the default user when developing with GLASS. Or, if it is possible to bootstrap GLASS into a stone for a user other than DataCurator, what’s the trick?


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: New user can't access GLASS & other classes

GLASS mailing list
Excellent! Thank you for clarification… this all makes sense of course.

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 10-07-2018, at 11:55 AM, James Foster <[hidden email]> wrote:

You are right that multiple roles might make more sense in production than in development. On the other hand, it still makes sense to separate the SystemUser (who owns the vendor-supplied kernel Globals) from the application development role. This prevents the application developer from accidentally (or intentionally) changing the core classes. One could still model different roles in development with DataCurator “owning” the application classes (placed in Published) and sample “users” who may have different application privileges and would “own” the data (perhaps in separate UserGlobal dictionaries). So, no, DataCurator is not mostly historic but provides a clear individual “developer” role (even if the developer is unnamed). Besides, while there are differences in scale and usage patterns between development and production, you wouldn’t say that transactions are only meaningful in production (even if a single developer is unlikely to have a conflict). Generally it makes sense to have the developer work in an environment modeled on production, and production won’t have multiple developer logins.

Even if you put all the developers in one database, you would probably want them to have separate copies of the code so that a halt put in by one would not be visible to another. If someone is rewriting a section then it should not be broken for others. So, while maybe you could isolate each user in the same database, why not just give each user their own database? With today’s hardware it is cheap enough. You would want to do SCM outside the repository anyway.

SCM options include (1) file-in/file-out in Topaz format (text files that can then be placed into Git or some other file-based SCM; (2) Monticello; and (3) FileTree/Tonel/Rowan (see https://github.com/dalehenrich/Rowan for more details).

James

On Jul 10, 2018, at 11:32 AM, Jerry Kott <[hidden email]> wrote:

I see… that seems like a reasonable solution. Although it kind of defeats the purpose of having multiple roles in each developer’s repository (the same thing could be achieved with a single high-privilege user), I can see how it would be applicable in the mult-user development team scenario. Would it be fair to say that DataCurator is there mostly for historic reasons, at least in the development stage? I can see how it would be more actively used in a deployed production environment, though…

Out of curiosity: what are the commonly used SCM systems with GemStone? I know GsDevKit uses Metacello to some degree, how about others? Are there frameworks / libraries for direct integration? Or is it more a ‘file-out’ / ‘commit’ type of use?

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 10-07-2018, at 11:06 AM, James Foster <[hidden email]> wrote:

Jerry,

In the old days (I started with GemStone about 20 years ago) it was common to have a single development database with multiple developers, and giving each their own login might be warranted as a security measure. Today I’d be inclined to give each developer their own repository and have them share code through an external source code management (SCM) system. With that you would maintain code ownership (through the SCM system). For those that are security conscious, it is common to have the system administrator load code into production directly from the SCM using a DataCurator password not known to the developers. If you really wanted to ensure developer isolation, you could give each developer a different repository with different passwords for DataCurator (and SystemUser). In any case, I’d be inclined to use DataCurator for development and isolate the repositories rather than the users.

James

On Jul 10, 2018, at 10:54 AM, Jerry Kott via Glass <[hidden email]> wrote:

Thanks for your reply, James.

Part of this is because of circumstances that were not my own choice. I have become somewhat of a security freak, and professional paranoia has become my SOP. I think of DataCurator as a privileged user (not quite like ‘root’ but close enough), as do most developers, I think. On a multi-developer team, I believe it’s essential to maintain code ownership, and using shared credentials of any kind (DataCurator or something else) makes that impossible. I would actually argue that letting DataCurator own the application on a production system (or another user with similar elevated privilege) is more appropriate than using it for development. I am sure this will depend on the context, such as the dynamics and the size of the development team, but from security perspective that’s what I would like to have.

At this moment, I am a single guy re-learning GemStone after 20 years of absence, so from a practical standpoint, using DataCurator for everything should be fine. But since I do want to understand the GS security model in-depth, I felt it was important for me to pretend I am on a multi-user team and only the ‘real’ data curator should be able to do certain things that other developers can not.

Cheers,

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 09-07-2018, at 1:47 PM, James Foster <[hidden email]> wrote:

Jerry,

I agree that it would be nice if the technology did not dictate a particular usage pattern, and I appreciate your recognition that there are a variety of factors involved in the community/open source project. Not as a way to convince you to do something else, but as a way for me to better understand people’s use of the system, I’d like to understand why you “really dislike the idea of developing as DataCurator”. While you are right that it doesn’t make sense to think of GemStone as a “single-user system” in a production sense, I wonder if it does make sense to think of it that way for development. Even for production, might it be best to think of it as a “single-application system” such that letting DataCurator own the application (as SystemUser owns the system)? What are your issues with DataCurator?

James

On Jul 9, 2018, at 1:27 PM, Jerry Kott via Glass <[hidden email]> wrote:

Some follow-up on the issue. I would like to extend my thanks to Richard Sargent who provided some useful tips in a private thread.

It turns out that "GLASS is designed to store code in DataCurator's UserGlobals. So everything loaded by Metacello would be loaded there.” I’ve tried several ways to get around it to be able to develop as a user other than DataCurator, unsuccessfully. Here are some of the things:

  1. I created JKTestGroup and JKTestUser. I made JKTestUser a member of all the predefined groups to make sure group membership itself is not an issue (in a real world scenario this would probably qualify as a bad practice).
  2. Then I did something that I was pretty sure was not going to be kosher (I was right) and it wouldn’t work (I was partially wrong):

    jkTestUser := AllUsers userWithId: 'JKTestUser’.
    jkUserGlobals := jkTestUser symbolList resolveSymbol: 'UserGlobals’.
    jkTestUser removeDictionaryAt: 1. “JKTestUser’s UserGlobals”
    jkTestUser insertDictionary: UserGlobals at: 1. “DataCurator’s UserGlobals”
    System commitTransaction.

    This allowed me to login as JKTestUser to a new session, and get the same info in the testLogin window as the DataCurator session. However, when I tried to do anything with the UserGlobals inserted into the test user symbol list, I started getting security violations. This was kind of expected as I didn’t think that sharing UserGlobals this way would be appropriate anyway, for several reasons. I just wanted to see if it was possible to bypass GS security by messing with the dictionaries this way. Apparently not :)
    I managed to get back the original UserGlobals into JKTestUser.

  3. I did a couple of variations on the above, e.g., directly copy classes from DataCurator’s UserGlobals dictionary to JKTestUser’s, each of the experiments would lead to a different kind of problems but security violations seem to be the most common.

  4. In my last experiment, I logged to my devKit stone with the topaz command line tool as JKTestUser and tried to input a .tpz file that I found GsDevKit uses to boostrap GLASS. The idea was that JKTestUser’s UserGlobals would have its own class hierarchy for GLASS etc. That didn’t work either, failed with compilation errors.


I understand GsDevKit is more ‘community’ oriented with large parts of the code base ported from Pharo/Seaside, and not really part of the GemStone/S product, so naturally there will be some limitations and possibly friction points. This probably has something to do with Pharo/Seaside being essentially a single user system. However, I really dislike the idea of developing as DataCurator, so I am thinking that I would create some abstract classes and new ‘globals’ in the Published dictionary pointing to GLASS stuff. That might provide access to the things that I need as a ‘developer’ user. Naturally, the tricky part here will be to get a useable IDE working. Tode will only work with the bootstrapped GLASS, so it’s a bit of a chicken and egg situation.

I wonder if others have similar experiences, or if people just use DataCurator as the default user when developing with GLASS. Or, if it is possible to bootstrap GLASS into a stone for a user other than DataCurator, what’s the trick?


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass





_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New user can't access GLASS & other classes

GLASS mailing list
In reply to this post by GLASS mailing list
First, thank you all who provided feedback, whether on this mailing list or in private emails.

I'll step back in the thread to keep the context ‘fresh’ ;)

I found that having a CodeModification privilege is helpful when you are trying to file in code through a .tpz file (DUH!). Once I added that privilege to the jkTestUser, I was able to do the point 4. below, and bootstrapped GLASS into the UserGlobals of the test user.

However, now when I try to login as JKTestUser, login fails because: MetacelloGemStonePlatform class does not understand  #’sessionStart’. Unfortunately the stack does not show all the frames up to the actual error so it’s tricky to find out exactly how it happens. I can see several senders of #sessionStart, and I can also see that in the DataCurator session, MetacelloGemStonePlatform class >> #initialize looks different (it just does ’super initialize’ instead of ‘….. self sessionStart’. It looks like there are two different versions of that method in the database, and depending on how you browse it, you’ll get one or the other.

It might be that there is a step I have missed after bootstrapping GLASS to adjust some initialization code? I am going to investigate if there is a way around this, but if this looks familiar to someone and could give me a hint, it would save me some time.

I love playing with GS!

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 09-07-2018, at 1:27 PM, Jerry Kott <[hidden email]> wrote:

Some follow-up on the issue. I would like to extend my thanks to Richard Sargent who provided some useful tips in a private thread.

It turns out that "GLASS is designed to store code in DataCurator's UserGlobals. So everything loaded by Metacello would be loaded there.” I’ve tried several ways to get around it to be able to develop as a user other than DataCurator, unsuccessfully. Here are some of the things:

  1. I created JKTestGroup and JKTestUser. I made JKTestUser a member of all the predefined groups to make sure group membership itself is not an issue (in a real world scenario this would probably qualify as a bad practice).
  2. Then I did something that I was pretty sure was not going to be kosher (I was right) and it wouldn’t work (I was partially wrong):

    jkTestUser := AllUsers userWithId: 'JKTestUser’.
    jkUserGlobals := jkTestUser symbolList resolveSymbol: 'UserGlobals’.
    jkTestUser removeDictionaryAt: 1. “JKTestUser’s UserGlobals”
    jkTestUser insertDictionary: UserGlobals at: 1. “DataCurator’s UserGlobals”
    System commitTransaction.

    This allowed me to login as JKTestUser to a new session, and get the same info in the testLogin window as the DataCurator session. However, when I tried to do anything with the UserGlobals inserted into the test user symbol list, I started getting security violations. This was kind of expected as I didn’t think that sharing UserGlobals this way would be appropriate anyway, for several reasons. I just wanted to see if it was possible to bypass GS security by messing with the dictionaries this way. Apparently not :)
    I managed to get back the original UserGlobals into JKTestUser.

  3. I did a couple of variations on the above, e.g., directly copy classes from DataCurator’s UserGlobals dictionary to JKTestUser’s, each of the experiments would lead to a different kind of problems but security violations seem to be the most common.

  4. In my last experiment, I logged to my devKit stone with the topaz command line tool as JKTestUser and tried to input a .tpz file that I found GsDevKit uses to boostrap GLASS. The idea was that JKTestUser’s UserGlobals would have its own class hierarchy for GLASS etc. That didn’t work either, failed with compilation errors.


I understand GsDevKit is more ‘community’ oriented with large parts of the code base ported from Pharo/Seaside, and not really part of the GemStone/S product, so naturally there will be some limitations and possibly friction points. This probably has something to do with Pharo/Seaside being essentially a single user system. However, I really dislike the idea of developing as DataCurator, so I am thinking that I would create some abstract classes and new ‘globals’ in the Published dictionary pointing to GLASS stuff. That might provide access to the things that I need as a ‘developer’ user. Naturally, the tricky part here will be to get a useable IDE working. Tode will only work with the bootstrapped GLASS, so it’s a bit of a chicken and egg situation.

I wonder if others have similar experiences, or if people just use DataCurator as the default user when developing with GLASS. Or, if it is possible to bootstrap GLASS into a stone for a user other than DataCurator, what’s the trick?

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5



On 03-07-2018, at 10:28 PM, Jerry Kott <[hidden email]> wrote:

Hello,

this pertains to GsDevKit with GS 3.4.1.

In a fresh client (tode1) I have created a new UserGroup (JKTestGroup), added a new UserProfile (JKTestUser) to it. Committed the transaction. I copied the content of my devKit_34 session profile and changed only the credentials. I have created a new client (tode2), in which I can see the two session profiles (devKit_34 and jkTest_34). I can log in to the stone (which is running on another host but that’s not a problem - I have ssh port forwarding set up and it works for both tode1 and tode2 clients). But when I do the ‘Test Login’ to jkTest_34 session, I get

Stone            : !@localhost#server!devKit_34
Stone host       : orion.local
GemStone version : 3.4.1
cpu kind         : x86_64
GLASS not installed
GLASS1 not installed
Tode not installed

whereas when I use the original devKit_34 session, I get the expected

Stone            : !@localhost#server!devKit_34
Stone host       : orion.local
GemStone version : 3.4.1
cpu kind         : x86_64
GLASS version    : >=1.0-beta.9.2.1 [ConfigurationOfGLASS]
Metacello version: >=1.0-beta.32.3 [ConfigurationOfMetacello]
GLASS1:
       repository: /gemstone/GsDevKit_home/shared/repos/glass/repository
Tode:
       repository: /gemstone/GsDevKit_home/shared/repos/tode/repository

I have tracked this to the UserGlobals in the DataCurator user profile having all the GLASS & Tode classes. I’ve tried several different ways to put them into the JKTestUser symbol dictionaries (insert a new one, or put the classes in the Published dictionary), but when I do that, I get an error ‘improper store’ with some parameters.

What should be a proper way to make the GLASS & Tode classes available to users other than DataCurator? Obviously I would like to do my development as a different user...

Jerry Kott
This message has been digitally signed. 
PGP Fingerprint:
A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5






_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

signature.asc (859 bytes) Download Attachment