User logging in must have OtherPassword privilege

[LisaAlmarode]

In order to login to Jadeite/Rowan, a user must have CodeModification (reasonably) and also OtherPassword. The error is a little confusing and only mentions CodeModificiation.

Since this is a one-person-per repository scenario it may not be critical... but generally you don't want just anyone to have OtherPassword since with that, they can change any other user's password, disable their commits, etc.

I imagine this is done to allow SymbolDictionary/SymbolList monkeying about with... maybe we have overworked the privilege.

[dalehenrich]

@LisaAlmarode Do you have a specific example of what happens when the user doesn't have OtherPassword --- I did not have a goal to require OtherPassword privileges for using Rowan:). You mention an error ... do you have a stack or the exact wording of the error message?

[LisaAlmarode]

[dalehenrich]

@LisaAlmarode, Thanks.

Now, if you could extract the stack that matches this error from the Jadeite ERRORS File we'd know what operation was involved ...

Presumably you are testing with a non-DataCurator/SystemUser user? Is OtherPassword privilege a privilege that we recommend for use by normal developers or is it reserved for folks with special privileges?

[LisaAlmarode]

No Jadeite.ERRORs file is to be found.

Yes, that was the point of the exercise - I created a new user to verify behavior. To merely log in, you must have CodeModication and OtherPassword, but no other permissions are required (to log in... more may be needed for other operations).

OtherPassword very much not recommended for normal developers, since normal developers should not be able to change one another's passwords nor disable one another from committing. As noted, however, it may not really matter in a single-user stone.

[LisaAlmarode]

Incidentally, the given dialog is followed by another dialog...

[dalehenrich]

I think we do want to track this one down ... @ericwinger I'm bouncing this to you to reproduce under a Dolphin debugger so we can understand a) what code is being executed to trigger this and b) to perhaps fix #173 ...

Not getting a stack from errors like this will make it difficult fir us to help users who run issues ...

[dalehenrich]

... once we get the stack, we can decide what needs to be done ...

@LisaAlmarode, did you happen to check if there was anything recorded in the gem log?

[ericwinger]

In order to create a user with different privileges, I need to know how to make Rowan visible to a non-DataCurator and non-SystemUser user. What is the easiest way to do that @dalehenrich?

My guess is that I need to modify their symbol list.

EDIT - Hmmm. This may not be my issue as from a VisualWorks GBS image logged into my Rowan stone, I can see Rowan in Globals. (Please ignore)

[dalehenrich]

In topaz, logged in as the user execute the following:

run
GsPackagePolicy current enable.
UserGlobals at: #rowanCompile put: true.
System commit
%

This is all we do for DataCurator ... Rowan is installed in Globals so it is visible to everyone with Globals in their symbol list --- the default symbol list I assume ...

[ericwinger]

@dalehenrich - I'm a little confused. I created a new user with all the privileges (in GBS in my rowan-enabled repository). However, when I try to login through Jadeite, it tells me that ROWAN_PROJECTS_HOME is nil.
Oddly, I can login as SystemUser and the env var is true.

Suggestions?

[dalehenrich]

what do you mean by env var is true ... ROWAN_PROJECTS_HOME should be a string not a boolean ... What does "all the privileges" mean ... I thought you were going to test a user with minimal privileges, not all of the privileges ...

First off, you probably need to verify logins by using an RPC login with topaz and check the env var ... the netldi shouldn't discriminate based upon which user is logging and the netldi is controlling the env vars for the gem process...

Secondly I would be suspicious that Jadeite is taking different paths depending upon the privileges of the user ...

[LisaAlmarode]

Nothing in the gem log. It is, incidentally, trivially easy to produce.

Create the user as DataCurator:

run AllUsers addNewUserWithId: 'Lisa' password: 'swordfish'. (AllUsers userWithId: 'Lisa') privileges: { 'CodeModification' } . System commitTransaction. %

Then try to login as Lisa with the password swordfish.

[ericwinger]

@dalehenrich - Problem fixed. I checked "No Perform on Server" by mistake when setting up my user.

[ericwinger]

@dalehenrich @LisaAlmarode First clue. The first error is from the compile of JadeServer code on the server. That code is called in GciSession>>initializeServer. The error handler wraps any error and throws up the first dialog Lisa saw.

I'll attach big ugly string that's being passed to server.

JadeCodeCompileString.txt

[dalehenrich]

Do you have details on what the error is ... CodeModification should allow us to compile methods, so I'm curious where the error is coming from ... can you post a stack?

[ericwinger]

Still working on getting a stack with more information. Next best thing so far is a dialog saying:

a SecurityError occurred (error 2151), reason: rtErrNoPriv, An attempt was made to do a privileged operation for which no privilege has been granted.

I verified I gave the user CodeModification privilege, and only that.

[dalehenrich]

You should be able to try executing the compile string in topaz and get a good stack ... I would think

[ericwinger]

No luck getting the string to run in topaz. Trying to get a stack by setting GEM_HALT_ON_ERROR to 2151 but can't get the gem to halt yet.

Maybe @LisaAlmarode or @dalehenrich can get a gem stack off GEM_HALT_ON_ERROR?

(Maybe that's not possible for security errors)

[dalehenrich]

When you say "no luck ,,, with topaz" what do you mean ... the string compiles correctly or ???

[dalehenrich]

Remember that Jadeite sets up a funky environment to do the compile (DataCurator UserGlobals among other things) ...

[ericwinger]

Looks like otherPassword was required in versions prior to GemStone 3.3 to compile code. http://kermit.gemtalksystems.com/bug?bug=44433

Therefore, I surmise (without stacks) that it's the code compilation done when initializing Jade on the server that's the problem.

[ericwinger]

When you say "no luck ,,, with topaz" what do you mean ... the string compiles correctly or ???

I massaged the string and put it in a file. Then I tried to input it into topaz. I changed the file to say run at the top but the delimiter for stopping the run % killed the input.

Effectively, I'm not yet topaz-savvy enough to get topaz to input a file built on smalltalk code to run.

[dalehenrich]

what does "killed the input" mean?

[dalehenrich]

... looks like you figured out the issue, good effort .... so it means that any developer will have OtherPassword privilege ...

[LisaAlmarode]

Well, with some monkey business I got the section of code that's invoking the privilege check. It's doing a SymbolList: add: in line 5 of the following long bit of code:

| class mcPlatformSupport methodClass readStream result server source symbolList writeStream |
methodClass := GsNMethod.
symbolList := System myUserProfile symbolList.
symbolList := (AllUsers userWithId: 'DataCurator') symbolList.
symbolList := symbolList class new add: (symbolList detect: [:each | each name == #UserGlobals]); add: (symbolList detect: [:each | ea
ch name == #Globals]); yourself.
[class := symbolList objectNamed: #Object.
class := class subclass: 'JadeServer'
                instVarNames: #('classList' 'classOrganizers' 'readStream' 'writeStream' 'selectedClass' 'methodFilterType' 'methodFil
ters' 'selections')
                classVars: #(ExternalInteger GciError GsObject OopType32 OopType64)
                classInstVars: #()
                poolDictionaries: (#() class withAll: symbolList)
                inDictionary: UserGlobals.
readStream := ReadStream on: 'implementorsOf: aGsMethod startingAt: aClass

        | selector myClass list |
        selector := aGsMethod selector.

<snip>

[ericwinger]

... looks like you figured out the issue, good effort .... so it means that any developer will have OtherPassword privilege ...

At least until we get JadeServer code into Rowan.

[LisaAlmarode]

Sorry, Dale, Eric doesn't have an answer - that bug only applied to the weird case where you were compiling a method into an Array rather than into a SymbolDictionary. It was not the case that anyone had OtherPassword before, they just didn't compile into Arrays.

[dalehenrich]

okay ... here's the SymbolList>>validatePrivilege method, and the comment seems to explain what's going on:

_validatePrivilege

"  
To modify your own SymbolList, you need #CodeModification.
To modify another's SymbolList, you need #OtherPassword.

Returns true if successful, otherwise signals an error and
if execution continued returns false.
"

| upro |
upro := System myUserProfile .
self == upro symbolList ifTrue:[
  ^ upro _validateCodeModificationPrivilege
] ifFalse:[
  self == GsSession currentSession symbolList ifTrue:[
    ^ upro _validateCodeModificationPrivilege
  ] ifFalse:[
    ^ upro _validatePrivilegeName: #OtherPassword
  ].
].

If I read this correctly (if I saw a stack it would be confirmed --- i.e. error coming from within SymbolList>>_validatePrivilege), the security error is being raised because Jade is creating a new symbol list and it is not the current user's symbol list nor is it the current session's symbol list...

I'm not exactly sure why it is necessary to fabricate a symbol list that includes DataCurator's UserGlobals ...

@LisaAlmarode do you know offhand if this is still the case in 3.4/3.5?

[dalehenrich]

@LisaAlmarode by the way when you include code or arbitrary text, you can avoid having html formatting rules invoked by putting the code between two lines of backticks ``` ... I'll edit the comment for readability ...

[ericwinger]

@dalehenrich - This may be the offending code. I wonder if it's a residue of when the JadeServer was compiled under it's own private symbol dictionary?

I removed the two >>>'d lines and I was able to login.

             nextPutAll: 'symbolList := System myUserProfile symbolList.'; lf;
       >>>>  nextPutAll: 'symbolList := (AllUsers userWithId: ''DataCurator'') symbolList.'; lf;
        >>>> nextPutAll: 'symbolList := symbolList class new add: (symbolList detect: [:each | each name == #UserGlobals]); add: (symbolList detect: [:each | each name == #Globals]); yourself.'; lf;

[dalehenrich]

If you are curious about why those two lines were added I suggest you look at the BLAME view for the file where that contains that code: It will tell you which commit those lines were added for and you can look at the commit comment and even changes for that commit ... I recall that there was a bugfix or two in that area and when I read the bug reports in the area, the changes had to do with "being allowed to create classes that were the same as those in the symbol list being viewed" or something like that .... I didn't dig too deep ... it seems that the changes were made a year or two ago which is pretty recent as things go, but the bug may be totally unrelated to what our needs are and if you can login, then that means the the JadeServer code compile without issue which is the goal --- Rowan itself does adds to symbol lists, but they are always the ones owned by the current user and those are allowed ...

[dalehenrich]

@ericwinger let's go ahead and include this two line change in the current candidate and see if we hit any other issues ...

[ericwinger]

I'll merge this change into candidate today.

EDIT - Err, umm, this is a Jadeite change so it'll be in the first post-Alpha2.0 release.

[ericwinger]

I've pushed this change to the Jadeite master branch, along with the tag Alpha2.0.1.

I did not cut a new Jadeite.exe. Can do so when needed.

[dalehenrich]

we can wait until we have a request for a new drop ...