[Glass] New user can't access GLASS & other classes

[Jerry Kott via Glass]

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 <Smalltalk at JGFoster.net> 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 <glass at lists.gemtalksystems.com <mailto:glass at lists.gemtalksystems.com>> 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:
>> 
>> 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).
>> 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.
>> 
>> 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.
>> 
>> 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?
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20180710/cb616106/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20180710/cb616106/attachment-0001.sig>