Re: Pier user in context

Hi Hans,

> hope you have has a nice trip to Toronto :-)

yep, Canada is great! The Pier & Magritte presentation was a success.

> One Question: in the PRContext>>user, there will be set property  
> user to nil if this property does not exist. Could that be  
> dangorous ? Should there be set some default user with smallest  
> rights ? (And should this user come from PRKernel as the smallest  
> user in current kernel or come from PRUser class as the smallest  
> thinkable user ?)

Yeah, this is not a nice design. Similar as the 'admin' user and  
'admin' role, there should be an 'anonymous' user and an 'anonymous'  
role. There are several checks for nil now, what makes it quite ugly  
in the oo-world, however I don't think this imposes any security  
risk ;-)

I will have a look at this as soon as possible.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> For security and web, I'm a little bit paranoid, especially at  
> such powerful systems like Pier ;-) I've discussed security in  
> Seaside/Pier with a friend, and from this I'm not sure today what I  
> expect from such systems like seaside/pier. He says, security  
> belongs only to buisness logic. I'm not so shure, also what to call  
> buisness logic in Pier...... I will  post a related question to the  
> list later.

If your friend means "model" when talking about "business logic", he  
is right: the security decoration is a pure model object, that works  
exactly the same for all views, not just seaside one. Thanks to the  
nature of visitors one can easily control how security concerns are  
handled when performing operations.

> You could help me understand the code answering the following  
> question: in your security package, every structure element  
> (decorator or the decorated element) has an owner, and the the  
> rights of that owner decide what is possible (that the UNIX way, I  
> think). Is that right ?

Yes, the code modeling the unix permissions is quite simple to read,  
of course you can tweak that behavior if you need to. I think it  
comes quite close what unix does, but I no unix expert.

SUSecurity>>isAllowedCommand: aCommandClass in: aContext
        (aContext user notNil and: [ aContext user isSuperuser ])
                ifTrue: [ ^ true ].
        (self owner = aContext user)
                ifTrue: [ ^ self ownerCommands includes: aCommandClass ].
        (self group notNil and: [ self group includes: aContext user ])
                ifTrue: [ ^ self groupCommands includes: aCommandClass ].
        ^ self otherCommands includes: aCommandClass

> But what about the commandos: is the security given by existence  
> (only the commandos in structure exist, which are executable) or by  
> right for execution for every commando (as in UNIX file system) ?  
> That I have not understand  until now.

I am not quite sure if I understand your question, maybe you can  
deduce the answer from the above code yourself?

Basically every security decoration knows a list of all allowed  
commands for the owner, the group and all the others, like the unix  
"rwx", but for all available commands in the system. The security  
decoration does not care what it decorates, e.g, when giving the  
permission to admin to remove the root page, he still won't be able  
to do that simply because the remove-command does not work on the  
root, something that is enforced by the command itself.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

Hi Lukas,

Am 30.04.2006 um 21:55 schrieb Lukas Renggli:

Yes, I know that this is a common way to think. What bothers me is  
this (from a naive point of view):

- security should not something which is only be added (thats the  
nature of decoration), because what was added can also be removed or  
forget to add. It seems more natural to me that security is deep in  
the mechanism of objects (or better message send), like the vats in E  
or Islands in Croquet.

- if one say model or buisness logic, one could easily think at the  
multi tier architectures. Here it is a common way to say, security  
must handled be the database objects (for example), not by the  
objects which are only a viewer. My problem is 1) that these viewers  
are mediators of security and 2) that in complex systems  this  
viewers can be itself complex object with model-view architecture.  
 From this I would naively think, that looking at security of  
buisness logic objects is not enough, or in other words, the  
partitioning in model-view is not unambiguous and (in some way)  
fractal. BTW, thats one point why I like Tweak, because it's  
architecture adresses this problem.

But maybe I'm only paranoid :-))

Thanks for the code example, it answers indeed my question.

Regards


Hans

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

Hi Lukas,

what I forgott: thanks for the answers, Lukas !

Regards

Hans


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> Yes, I know that this is a common way to think. What bothers me is
> this (from a naive point of view):
>
> - security should not something which is only be added (thats the
> nature of decoration), because what was added can also be removed or
> forget to add.

Well, as soon as the unix security package is loaded, the security  
decoration adds itself automatically to all newly created structures.  
There is no easy way, except by manually editing the object-graph  
from the inspector, to add or remove security decorations.

> It seems more natural to me that security is deep in
> the mechanism of objects (or better message send), like the vats in E
> or Islands in Croquet.

In my opinion this is something different. I want to keep as much as  
possible pluggable in Pier, so that users with different needs can  
use different security systems. There are already two security  
frameworks that both work nicely, that both have advantages and  
disadvantages, and that every user can decide to use or not to use.

> - if one say model or buisness logic, one could easily think at the
> multi tier architectures. Here it is a common way to say, security
> must handled be the database objects (for example), not by the
> objects which are only a viewer. My problem is 1) that these viewers
> are mediators of security and 2) that in complex systems  this
> viewers can be itself complex object with model-view architecture.

In Pier the security is not handled by the view, but by the model.  
That is also the reason why it works in the Seaside view and in the  
OmniBrowser view without additional code.

> From this I would naively think, that looking at security of
> buisness logic objects is not enough, or in other words, the
> partitioning in model-view is not unambiguous and (in some way)
> fractal. BTW, thats one point why I like Tweak, because it's
> architecture adresses this problem.

Yeah, this is true for Pier. Some logic had to be duplicated in  
different views, because the (meta-)model (Magritte) is unable to  
handle it in a generic way, e.g. when rendering links to HTML or a  
pretty printed Text-Stream I have in both cases to manually check the  
permission to be able to render the link disabled, however even it  
would not be rendered disabled users would be unable to navigate  
there because this would activate an invalid-context and the context  
is part of the model.

Hope this clarifies some things,
Lukas

Side-note: I do not claim that the security model of Pier is secure  
and impossible to break, as with everything I write as open-source it  
suits my personal needs. Bug-reports, fixes and enhancements are  
always welcome.

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

Hi,

Yes, this is clear (because decorators are part of model) if looking  
at "Seaside only" solutions. My statement above was made by thinking  
Seaside/Pier itself as a view in a greater solution. But ok, where to  
draw the borders between model and view may be somewhat academic :-)

>>
>
> Hope this clarifies some things,

Oh, I understand the implementation in Pier, and also the intention.  
I only want to play with a different point of view ;-)

>
> Side-note: I do not claim that the security model of Pier is secure
> and impossible to break, as with everything I write as open-source it
> suits my personal needs. Bug-reports, fixes and enhancements are
> always welcome.

Hey ! Don't be angry, I know the rules of open-source, and I never  
want to be destructive. I'm only interested in different point of  
views,  discussions and the question "why ?" 8-) So thank you very  
much for the answers. I hope we could talk a little bit further at  
some SqueakNic or something like this :-)

Greetings

Hans

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

Lucas, is there a particular reason that Pier doesn't allow WATask
subclasses to be added as components?


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> Lucas, is there a particular reason that Pier doesn't allow WATask
> subclasses to be added as components?

Actually subclasses of WATask should work. In some older versions of  
Pier there was a bug that a WATask rendered empty on the first  
request, however I think this problem is solved in current versions  
of Pier.

Can you give some more details about your task?

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki

> Actually subclasses of WATask should work. In some older
> versions of Pier there was a bug that a WATask rendered empty
> on the first request, however I think this problem is solved
> in current versions of Pier.
>
> Can you give some more details about your task?
>
> Cheers,
> Lukas

My bad, I'd forgotten to add canBeRoot on the class side, wasn't showing
up in the component list.  Works fine.


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Smallwiki mailing list
[hidden email]
http://impara.de/mailman/listinfo/smallwiki