On Feb 27, 2007, at 10:27 , Hilaire Fernandes wrote:

I have found this strange error, with squeakland (with up to date update)

If I load a project from a superwiki, then I save the image I got an error and the image is not saved. It is a primitive error, and it is looking like Squeak try to create a /home directory (which it is not authorized to)

If then, I reload the project from the downloaded project in the squeaklet directory, then I can save just fine the image.

Could you forward the SqueakDebug.log file that was created when the error occurred?

- Bert -

Thanks. Is it possible your image directory was write-protected? The log indicates it was trying to create the default directory but failed. I can't imaging how that could have to do with the project loaded, unless it fiddled with the default directory path.

- Bert -

On Feb 27, 2007, at 12:14 , Hilaire Fernandes wrote:

Bert Freudenberg a écrit :

...

Could you forward the SqueakDebug.log file that was created when the error occurred?

Here it is.

Hilaire Error: a primitive has failed 27 February 2007 10:23:28 am

VM: unix - a SmalltalkImage Image: Squeakland 3.8-05 [latest update: #552]

SecurityManager state: Restricted: true FileAccess: false SocketAccess: true Working Dir /home/hilaire/Documents/CDDP/Animations/2007-03-28/My Squeak Trusted Dir /home/hilaire/Documents/CDDP/Animations/2007-03-28/secure Untrusted Dir /home/hilaire/Documents/CDDP/Animations/2007-03-28/My Squeak

UnixFileDirectory(Object)>>error: Receiver: UnixFileDirectory on '/' Arguments and temporary variables: t1: 'a primitive has failed' Receiver's instance variables: pathName: FilePath('/')

UnixFileDirectory(Object)>>primitiveFailed Receiver: UnixFileDirectory on '/' Arguments and temporary variables:

Receiver's instance variables: pathName: FilePath('/')

UnixFileDirectory(FileDirectory)>>primCreateDirectory: Receiver: UnixFileDirectory on '/' Arguments and temporary variables: t1: '/home' Receiver's instance variables: pathName: FilePath('/')

UnixFileDirectory(FileDirectory)>>createDirectory: Receiver: UnixFileDirectory on '/' Arguments and temporary variables: t1: 'home' Receiver's instance variables: pathName: FilePath('/')

--- The full stack --- UnixFileDirectory(Object)>>error: UnixFileDirectory(Object)>>primitiveFailed UnixFileDirectory(FileDirectory)>>primCreateDirectory: UnixFileDirectory(FileDirectory)>>createDirectory:

---

UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistenceOfPath: UnixFileDirectory(FileDirectory)>>assureExistence FileDirectory class>>startUp FileDirectory class(Behavior)>>startUp: [] in SystemDictionary>>send:toClassesNamedIn:with: {[:t6 | t5 := self at: t6 ifAbsent: []. t5 ifNil: [t4 add: t6] ...]} OrderedCollection>>do: SystemDictionary>>send:toClassesNamedIn:with: SystemDictionary>>processStartUpList: SmalltalkImage>>snapshot:andQuit:embedded: SmalltalkImage>>snapshot:andQuit: SmalltalkImage>>saveSession TheWorldMenu>>doMenuItem:with: [] in MenuItemMorph>>invokeWithEvent: {[(t2 := selector numArgs) = 0 ifTrue: [target perform: selector] ifFalse...]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: MenuItemMorph>>invokeWithEvent: MenuItemMorph>>mouseUp: MenuItemMorph>>handleMouseUp: MouseButtonEvent>>sentTo: MenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuItemMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuMorph(Morph)>>processEvent:using: MenuMorph(Morph)>>processEvent: MenuMorph>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := t1. t4 := t2 handleFocusEvent: (t1...]} [] in PasteUpMorph>>becomeActiveDuring: {[t1 value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: {[:t3 | ActiveHand := t3. t3 processEvents. t2 := t2 or: [t3 isCapturi...]} Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor yield. false] whileFalse. nil]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]} _______________________________________________ Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland

Okay, so you can reproduce this. In the debugger, can you check which directory it's actually trying to ensure exists? And find out why that fails?

- Bert -

On Mar 2, 2007, at 9:55 , Hilaire Fernandes wrote:

No Bert my directory is not write protected, let me explain the operation I conducted:

• working in my squeakland image (a copy of it in another folder than

the default one, and I start it with squeakvm)

• I create and edit my project with this image, I can save the image

just fine

• I load a project from our swiki (with my squeakland configure

with the smalltalk code at http://superswiki.ofset.org:8000/super/16)

• I save the image ==> error. From there whatever I do (remove the

loaded project), I cannot save the image

• I quit squeak and restart it, with the last saved image (before

the bang)

• I reload the downloaded project, but from the local copy now in 'My

Squeak, This time I can save the image just fine.

Hope it helps,

Hilaire

Bert Freudenberg a écrit :

...

Thanks. Is it possible your image directory was write-protected? The log indicates it was trying to create the default directory but failed. I can't imaging how that could have to do with the project loaded, unless it fiddled with the default directory path.

---

Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland

No, what I mean is, what directory was it trying to create originally. You have to look in the debugger stack where the first assureExistence is called to see that directory.

- Bert -

On Mar 2, 2007, at 12:41 , Hilaire Fernandes wrote:

Sure, it is trying to create the /home directory, odd don't you? At first I was wondering if I was analysing correcty.

I load a .pr which does not produce this problem. Form superwiki ofset.org:8000

• the pb arised with 'v-toys voiture sur route-7.pr'
• the does not arise with 'modele de diapo inter-2'

Both project are at top of the list.

Does it produce the same pb for you?

Hilaire

Bert Freudenberg a écrit :

...

Okay, so you can reproduce this. In the debugger, can you check which directory it's actually trying to ensure exists? And find out why that fails?

Recheck again at home and I can reproduce the same problem.

Load from swiki a project then save image under a different name, so:

Smalltlalk>>saveImageinFileName:t1 t1='/home/hilaire/.npsqueak/My Squeak/SqueakPlugin.1.image'

Then the recursive call of 'assureExistenceOfPath: t1' go up to home, then the call primCreateDirectory t1 with t1='/home' It is then primitive land, which I don't know

I will look at the OLPC version.

Hilaire

Hilaire Fernandes a écrit :

Bert Freudenberg a écrit :

...

No, what I mean is, what directory was it trying to create originally. You have to look in the debugger stack where the first assureExistence is called to see that directory.

Strangely it was not clear as I did not see any absolute pathname, only successive directory. However it was looking like it starts down from 'My Squeak' folder. I will give it a serious check later next week as I was in hurry recently.

Hilaire

...

• Bert -

On Mar 2, 2007, at 12:41 , Hilaire Fernandes wrote:

...

Sure, it is trying to create the /home directory, odd don't you? At first I was wondering if I was analysing correcty.

I load a .pr which does not produce this problem. Form superwiki ofset.org:8000

• the pb arised with 'v-toys voiture sur route-7.pr'
• the does not arise with 'modele de diapo inter-2'

Both project are at top of the list.

Does it produce the same pb for you?

Hilaire

Bert Freudenberg a écrit :

...

Okay, so you can reproduce this. In the debugger, can you check which directory it's actually trying to ensure exists? And find out why that fails?

Bert Freudenberg wrote:

The debug log you attached before shows that your image was in restricted mode. In this sandbox mode, you are only allowed to write inside the SecurityManager's "untrusted directory". I don't think you're even supposed to save the image when in sandbox mode, so if you try anyway, there might be any number of bugs lurking. IIRC the image save logic assumes that FileDirectory default and the image directory are identical. But in sandbox mode, this is not true anymore.

That is correct. With the sandbox on, you can't safe the image - otherwise this would be a trivial way for a malicious bit of code to make itself forever at home in that image.

Cheers, - Andreas

On Mar 3, 2007, at 8:11 , Andreas Raab wrote:

Bert Freudenberg wrote:

...

The debug log you attached before shows that your image was in restricted mode. In this sandbox mode, you are only allowed to write inside the SecurityManager's "untrusted directory". I don't think you're even supposed to save the image when in sandbox mode, so if you try anyway, there might be any number of bugs lurking. IIRC the image save logic assumes that FileDirectory default and the image directory are identical. But in sandbox mode, this is not true anymore.

That is correct. With the sandbox on, you can't safe the image - otherwise this would be a trivial way for a malicious bit of code to make itself forever at home in that image.

Well, you should be able to save the image in the untrusted directory, right? Squeakland users usually never save the image, and Squeak.org users never enable the sandbox, so there might well be bugs hidden there.

- Bert -

On Mar 3, 2007, at 8:15 , Hilaire Fernandes wrote:

Hilaire Fernandes a écrit :

...

I will look at the OLPC version.

With etoy-dev-2 and update, the problem does not show up.

The dev images do not have the sandbox enabled. See Andreas' mail - this is intended behavior.

- Bert -

Hilaire Fernandes a écrit :

Hilaire Fernandes a écrit :

...

I will look at the OLPC version.

With etoy-dev-2 and update, the problem does not show up.

So may be there is a security risk there. Well, in my scenario, there is an explicit superswiki registered in the image, may be it can not be the case for the olpc version.

Hilaire