Security, Segments and login users

Hi,

now that I'm quite comfortable with using gemstone it seems I need to reach the next level. It might be embarrasing that I didn't think a single moment about the setup of gemstone overall so far. I just installed it and took the scripts provided by the installation. But then I think most of us are doing it this way.

Anyway, I shifted most of my work towards gemstone and I'm collecting pier instances on my server. Three weeks ago I gave a pier installation to a friend of mine. At this time I thought about security the first time. Not too much because I trust my friend and his technical skills won't lead him to damage anything.

Now I want to offer a pier instance to the newly created smalltalk user group here in cologne. Before giving the instance away I want to be sure to set it up correctly. I saw some of the videos by James Foster about gemstone and finally I started reading the gemstone programmer manual (I know....). I have to say that I'm deeply impressed by the architecture and possibilities in gemstone.

What I want to achieve:

- having pier instances separated from each other in the best possible way
- separating classes from pier instances. If you add a component I don't want to see the components of the other installations
- prevent side effects from installation to another

What I can imagine by now:

- I need to stop using the DataCurator user to provide seaside services.
- I can use UserGlobals/UserGlasses and/or Segment to separate data/code from each other.
- In a one user - one application scenario I think UserGlobals/UserClasses will do the trick alone
- In a shared scenario I need segments
- pier manages its instances on the class side. To protect kernels from each other I need to put them in separate segments
- my application objects I can still put in UserGlobals as they are only accessed by one application. Is there a way to collect instances on the class side and still have them separated by users?
- to separate e.g. pier widgets I need separate users (UserClasses) or separate segments. A good approach might be to have segments below the DataCurator segment for the different code setups and have segments for each pier kernel below one of these segments.

There a quite a few possibilities to set up. There is one thing that I don't understand. UserGlobals/UserGlasses are dependent on a user. Segments depend on a user, too. In order to provide seaside services I start e.g. a FastCGI instance that uses one particular user to log in. The only approach I could imagine how to solve this is to use dedicated fast cgi instances. I would start one fast cgi instance per user. This way I would assign port -> user. In lighttpd I would assign an incoming hostname:port (application) to a fast cgi port (user). This way I would have dedicated users per application and could build segments with access rights accordingly. I would hope there is somethig more flexible how this can be solved. As soon as some starts to load balance you would need

load balancing servers x application

images to run on the machine. I looked at the startSeaside_FastCGI script and to me it appears that the login of a user is a more heavyweight operation. So it might not be possible to switch a user on a per request basis. What to do best?

thanks in advance,

Norbert

Hi,

> What I want to achieve:
>
> - having pier instances separated from each other in the best possible way

Do you need to run the pier sites inside the same gemstone instance?
It may be easier to use separate instances, unless you have data that
you need to share. You just create a different config, different
extent and tranlog directories and start your stone.

> - separating classes from pier instances. If you add a component I don't want to see the components of the other installations
> - prevent side effects from installation to another

Again, easier in different instances. But, it is possible to do this
in the same instance. Each user (UserProfile) have its own symbolList.
UserGlobals is intended to be a space local to each user, i.e. it is
an instance of SymbolDictionary created when you create a UserProfile.
You may share symbolDictionaries amongst users, which gives you shared
classes / objects. You can separate also by just adding a new
symbolDictionary into the user's symbol list and then get all the code
to load into this symbol dict. In this case the code is totally
separated. (except for Globals, which is a symbol dict that is shared.
(You could probably localise this for each user as well!?)

> - In a shared scenario I need segments
> - pier manages its instances on the class side. To protect kernels from each other I need to put them in separate segments

If you have separate classes for each user, the instances will then be
separated. This implies that you'll have to log in the database as a
different user depending on the site you are serving. Quite possible
to do. Different instances also.

> - my application objects I can still put in UserGlobals as they are only accessed by one application. Is there a way to collect instances on the class side and still have them separated by users?
> - to separate e.g. pier widgets I need separate users (UserClasses) or separate segments. A good approach might be to have segments below the DataCurator segment for the different code setups and have segments for each pier kernel below one of these segments.
> There a quite a few possibilities to set up. There is one thing that I don't understand. UserGlobals/UserGlasses are dependent on a user. Segments depend on a user, too. In order to provide seaside services I start e.g. a FastCGI instance that uses one particular user to log in. The only approach I could imagine how to solve this is to use dedicated fast cgi instances. I would start one fast cgi instance per user. This way I would assign port -> user. In lighttpd I would assign an incoming hostname:port (application) to a fast cgi port (user). This way I would have dedicated users per application and could build segments with access rights accordingly. I would hope there is somethig more flexible how this can be solved. As soon as some starts to load balance you would need
>
> load balancing servers x application
>
> images to run on the machine. I looked at the startSeaside_FastCGI script and to me it appears that the login of a user is a more heavyweight operation. So it might not be possible to switch a user on a per request basis. What to do best?


I think segments is an overkill for what you want to do. This will be
more applicable in the case where if the logged in user must not be
able to see certain objects. This is protected at the object level. I
think you will use the same (db) user for a particular site because
this user will stay logged in and keep on serving pages through the
same session.

Cheers
Otto

Hi Otto,

On 24.02.2010, at 12:59, Otto Behrens wrote:
I could make separate gemstone instances. There is no need for the applications/piers to be in the same stone. At the moment I like to discover what is possible to do. On the other hand the pier instances are really small. Copying the whole database for a single pier instance seems a bit heavy weight for me. If I understood it correctly than every stone has its own shared page cache, symbol gem, gc gem, etc.? It is a lot more!
At the moment I'm using DataCurator as my user. That could be the reason why I don't know how this works. If I'm a different user and I load a new package where are the classes attached to? Is it the users symbol list? That would be good. Then I only need to log in as that user and use metacello there.

>> - In a shared scenario I need segments
>> - pier manages its instances on the class side. To protect kernels from each other I need to put them in separate segments
>
> If you have separate classes for each user, the instances will then be
> separated. This implies that you'll have to log in the database as a
> different user depending on the site you are serving. Quite possible
> to do. Different instances also.
>
My idea was that PRKernel class could be globally available but the kernels that are in PRKernel>>instances would point to different segments/user space. Or something similar.
Ok, thanks. I don't really like the idea to have a complete stone for just one pier instance. To start with this kind of setup I'll probably make a user for each pier instance and start a fast cgi for it. This way I can share the shared page cache and maintenace gems. I would then try to load the code into each of the users just to be sure. With the new bootstrapping facility that Dale provided this could go quite easily. I could boostrap the minimal image and then I would load additional things like seaside, magritte, pier into each user space. This way I can collect some experience and I'm able to update every instance on its own.

Norbert

> Ok, thanks. I don't really like the idea to have a complete stone for just one pier instance. To start with this kind of setup I'll probably make a user for each pier instance and start a fast cgi for it. This way I can share the shared page cache and maintenace gems. I would then try to load the code into each of the users just to be sure. With the new bootstrapping facility that Dale provided this could go quite easily. I could boostrap the minimal image and then I would load additional things like seaside, magritte, pier into each user space. This way I can collect some experience and I'm able to update every instance on its own.

Yes, you'll have to load the code for each user. You'll have a
different instance of the class PRKernel for each user, which implies
a different instance of the classVar / classInstVar which keeps
instances. You should get away with using UserGlobals, since
UserGlobals should be unique for each user. Not sure if there are any
assumptions in the "GLASS" code about the DataCurator user, but that
would be unexpected.

Thinking of this, we might try it out as well! Great idea.

Cheers
Otto

Regarding getting away from using Class Vars.

James and I have been looking at this problem of sharing code across multiple GemStone users and separating the persistent state from the code is beginning to look like a good idea. As Otto mentions, UserGlobals is unique for every user, but to ensure that your code access the correct UserGlobals, you need to look up UserGlobals when you reference it. Direct references to the global UserGlobals will be resolved at compile time ... so they will be bound to the user that loaded the code, not necessarily the user that is running the code.

There shouldn't be any assumptions in the GLASS system about DataCurator ... we have unit tests that get run installing and running tests as a non-DataCurator user.

Dale
----- "Otto Behrens" <[hidden email]> wrote:

| > Ok, thanks. I don't really like the idea to have a complete stone
| for just one pier instance. To start with this kind of setup I'll
| probably make a user for each pier instance and start a fast cgi for
| it. This way I can share the shared page cache and maintenace gems. I
| would then try to load the code into each of the users just to be
| sure. With the new bootstrapping facility that Dale provided this
| could go quite easily. I could boostrap the minimal image and then I
| would load additional things like seaside, magritte, pier into each
| user space. This way I can collect some experience and I'm able to
| update every instance on its own.
|
| Yes, you'll have to load the code for each user. You'll have a
| different instance of the class PRKernel for each user, which implies
| a different instance of the classVar / classInstVar which keeps
| instances. You should get away with using UserGlobals, since
| UserGlobals should be unique for each user. Not sure if there are any
| assumptions in the "GLASS" code about the DataCurator user, but that
| would be unexpected.
|
| Thinking of this, we might try it out as well! Great idea.
|
| Cheers
| Otto