exist-development

[Exist-development] security refactoring

[Dmitriy S. <sha...@gm...>]

Hello,

I want to add new accounts: 

 - 'system account' (id = 0, dba group), it will be use by system only.
It will be useful as owner of the /system resources, so it will be never
modified by anybody, only by system it self (throw special functions);

 - 'nobody' (id = -1, guest group), the use didn't offer himself. This
account can't be used as resource owner.

Next in my plan (next two weeks):

 - change the major version number of the security subsystem;

 - add collection /system/security, it will be use for setting, accounts
and roles information;

 - use collections: /system/security/( internal, openid, ldap,
activeDirectory) & etc, one per realm, other words each realm will have 
separate collection. 

 - each realm's collection will have subcollection: role (or should I
use 'group' as name?), user & file: settings.xml (I'll implement runtime
reconfiguration)

 - each group or user will be at single file.

(I will put converter to transform old structure to new one)

Any comments?

-- 
Cheers,

Dmitriy Shabanov

Re: [Exist-development] security refactoring

[Dmitriy S. <sha...@gm...>]

The trunk is POSSIBLE UNSTABLE, please let me know if any problem.

Should I change storage version (.dbx file) to force backup/restore,
because of new security storage structure?

Should it be converted automatic or manual? (I think of manual way,
pluggable realms will be turned off and only internal one (users.xml)
will operate)

-- 
Cheers,

Dmitriy Shabanov

On Fri, 2010-07-16 at 00:12 +0500, Dmitriy Shabanov wrote:
> Hello,
> 
> I want to add new accounts: 
> 
>  - 'system account' (id = 0, dba group), it will be use by system only.
> It will be useful as owner of the /system resources, so it will be never
> modified by anybody, only by system it self (throw special functions);
> 
>  - 'nobody' (id = -1, guest group), the use didn't offer himself. This
> account can't be used as resource owner.
> 
> Next in my plan (next two weeks):
> 
>  - change the major version number of the security subsystem;
> 
>  - add collection /system/security, it will be use for setting, accounts
> and roles information;
> 
>  - use collections: /system/security/( internal, openid, ldap,
> activeDirectory) & etc, one per realm, other words each realm will have 
> separate collection. 
> 
>  - each realm's collection will have subcollection: role (or should I
> use 'group' as name?), user & file: settings.xml (I'll implement runtime
> reconfiguration)
> 
>  - each group or user will be at single file.
> 
> (I will put converter to transform old structure to new one)
> 
> Any comments?
> 

Re: [Exist-development] security refactoring

[Dannes W. <da...@ex...>]

if the dbx format is changed,  you should update a 'magic number', identifying a dbx-model update. Exist refuses to startup  when there is a difference between javacode and the code stored in the dbx files.

The only way to pass this, is a backup-restore.

These kind of changes are acceptable for trunk (not too often), but should be announced on the mailing list and in the commit message. Between versions (1.4.0 1.4.1) these changes are acceptable as well.

D.

On 21 Jul 2010, at 19:53 , Dmitriy Shabanov wrote:

> The trunk is POSSIBLE UNSTABLE, please let me know if any problem.
> 
> Should I change storage version (.dbx file) to force backup/restore,
> because of new security storage structure?
> 
> Should it be converted automatic or manual? (I think of manual way,
> pluggable realms will be turned off and only internal one (users.xml)
> will operate)

Kind regards

Dannes

--
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

Re: [Exist-development] security refactoring

[Adam R. <ad...@ex...>]

>  - 'system account' (id = 0, dba group), it will be use by system only.
> It will be useful as owner of the /system resources, so it will be never
> modified by anybody, only by system it self (throw special functions);

fine :-)

>  - 'nobody' (id = -1, guest group), the use didn't offer himself. This
> account can't be used as resource owner.

How is this any different to the current 'guest' user?

> Next in my plan (next two weeks):
>
>  - change the major version number of the security subsystem;
>
>  - add collection /system/security, it will be use for setting, accounts
> and roles information;
>
>  - use collections: /system/security/( internal, openid, ldap,
> activeDirectory) & etc, one per realm, other words each realm will have
> separate collection.
>
>  - each realm's collection will have subcollection: role (or should I
> use 'group' as name?), user & file: settings.xml (I'll implement runtime
> reconfiguration)
>
>  - each group or user will be at single file.
>
> (I will put converter to transform old structure to new one)
>
> Any comments?
>
> --
> Cheers,
>
> Dmitriy Shabanov
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] security refactoring

[Dmitriy S. <sha...@gm...>]

!WARNING!

I'm on a way to commit this changes, let me know if any problem & please
do a back-up!

On Wed, 2010-07-21 at 22:04 +0100, Adam Retter wrote:
> >  - change the major version number of the security subsystem;
> >
> >  - add collection /system/security, it will be use for setting,
> accounts
> > and roles information;
> >
> >  - use collections: /system/security/( internal, openid, ldap,
> > activeDirectory) & etc, one per realm, other words each realm will
> have
> > separate collection.
> >
> >  - each realm's collection will have subcollection: role (or should
> I
> > use 'group' as name?), user & file: settings.xml (I'll implement
> runtime
> > reconfiguration)
> >
> >  - each group or user will be at single file.

-- 
Cheers,

Dmitriy Shabanov

Re: [Exist-development] security refactoring

[Dmitriy S. <sha...@gm...>]

On Wed, 2010-07-21 at 22:04 +0100, Adam Retter wrote:
> >  - 'system account' (id = 0, dba group), it will be use by system only.
> > It will be useful as owner of the /system resources, so it will be never
> > modified by anybody, only by system it self (throw special functions);
> 
> fine :-)
> 
> >  - 'nobody' (id = -1, guest group), the use didn't offer himself. This
> > account can't be used as resource owner.
> 
> How is this any different to the current 'guest' user?

Current "guest" account can be used by user (authenticate), I do miss
something before user introduce oneself. This account should not be
allowed to create anything @database, but only limited read permissions.

-- 
Cheers,

Dmitriy Shabanov

Re: [Exist-development] security refactoring

[Adam R. <ad...@ex...>]

>> How is this any different to the current 'guest' user?
>
> Current "guest" account can be used by user (authenticate), I do miss
> something before user introduce oneself. This account should not be
> allowed to create anything @database, but only limited read permissions.

Sure but this problem is really due to the default permission on /db.
Arguably you just need to tighten these up and then the guest user
would be fine.

> --
> Cheers,
>
> Dmitriy Shabanov
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] security refactoring

[Dmitriy S. <sha...@gm...>]

On Thu, 2010-07-22 at 09:36 +0100, Adam Retter wrote:
> >> How is this any different to the current 'guest' user?
> >
> > Current "guest" account can be used by user (authenticate), I do miss
> > something before user introduce oneself. This account should not be
> > allowed to create anything @database, but only limited read permissions.
> 
> Sure but this problem is really due to the default permission on /db.
> Arguably you just need to tighten these up and then the guest user
> would be fine.

We are talking different things here. You are on authorization side &
I'm on authentication one.

Personally, I don't like default account & role for permissions (default
mask is ok), the user must introduce oneself or we have security hole.
(linux security system don't allow this, you have to authenticate first)

-- 
Cheers,

Dmitriy Shabanov