From: Adam R. <ad...@ex...> - 2010-09-27 11:17:51
|
At present a lot of the operations around permissions are restricted to users in the DBA group. This is a artificial restriction that we have imposed to try and keep a high level of security. I think that this is a legacy, which in fairness was required, before Dmitriy's excellent work to modernise and massively improve the security architecture in eXist-db. However, I have two use cases (and there are probably others), whereby I need to decompose the security architecture in eXist-db further to allow us to build good web applications, where security can be managed by appropriately by authorised and authenticated users. Use Case 1 ---------------- A user creates a group, and then later wishes to remove the group. Problem - At present anyone can create a group, BUT only users in the DBA group can delete a group. It is undesirable to make all users DBA as this gives them complete control over the running eXist-db instance. Use Case 2 ---------------- A user creates a group, and then needs to be able to invite other users into his group for the purposes of sharing data. Problem - At present anyone can create a group, BUT only users in the DBA group can add a user to a group. Proposed Solution -------------------------- Introduce the concept of ownership of a groups. The user who creates a group, is the owner of that group. e.g. If the user "User A" creates a group "Group 1", he is the owner of the group "Group 1". 1) "User A" can add any other user to "Group 1", because he is the owner of that group. 2) Any user can remove themselves from any group they choose - I cannot think of a case where downgrading a users rights prevents a security risk. This is the users right! 3) "User A" can also delete "Group 1" when he choose because he is the owner of that group. Again this is a case of downgrading users rights. Thanks Adam. -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Chris T. <chr...@gm...> - 2010-09-27 11:41:40
|
+1 and I would suggest that a group owner may add other users as owners so that User A can leave the group after User B has been made an owner. Presumably members of group dba will continue to have complete control. This sort of mechanism obviously will get rid of "business policy" code that checks group membership for a user and then authenticates as a dba user in order to do these sorts of group management functions. Chris On Sep 27, 2010, at 5:02 PM, Adam Retter wrote: > At present a lot of the operations around permissions are restricted > to users in the DBA group. This is a artificial restriction that we > have imposed to try and keep a high level of security. I think that > this is a legacy, which in fairness was required, before Dmitriy's > excellent work to modernise and massively improve the security > architecture in eXist-db. > > However, I have two use cases (and there are probably others), whereby > I need to decompose the security architecture in eXist-db further to > allow us to build good web applications, where security can be managed > by appropriately by authorised and authenticated users. > > Use Case 1 > ---------------- > A user creates a group, and then later wishes to remove the group. > > Problem - At present anyone can create a group, BUT only users in the > DBA group can delete a group. It is undesirable to make all users DBA > as this gives them complete control over the running eXist-db > instance. > > > Use Case 2 > ---------------- > A user creates a group, and then needs to be able to invite other > users into his group for the purposes of sharing data. > > Problem - At present anyone can create a group, BUT only users in the > DBA group can add a user to a group. > > > > Proposed Solution > -------------------------- > Introduce the concept of ownership of a groups. The user who creates a > group, is the owner of that group. > > e.g. If the user "User A" creates a group "Group 1", he is the owner > of the group "Group 1". > 1) "User A" can add any other user to "Group 1", because he is the > owner of that group. > 2) Any user can remove themselves from any group they choose - I > cannot think of a case where downgrading a users rights prevents a > security risk. This is the users right! > 3) "User A" can also delete "Group 1" when he choose because he is the > owner of that group. Again this is a case of downgrading users rights. > > Thanks Adam. > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development |
From: Evgeny G. <gaz...@gm...> - 2010-09-27 11:53:28
|
Another side: I'm a user B and I'm owner of me :) So I won't be added to group C, for example, by owner of group C. :) So where better store the links between groups and accounts? in group doc? or in account doc? -- Evgeny |
From: Adam R. <ad...@ex...> - 2010-09-27 12:26:16
|
> Another side: I'm a user B and I'm owner of me :) > So I won't be added to group C, for example, > by owner of group C. Actually you would be - this is not a security issue. If an owner of a group invites you into a group that he has created then that is legitimate. You can then if you wish, remove yourself from that group which again is a legitimate operation without security leaks. -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Dmitriy S. <sha...@gm...> - 2010-09-27 12:04:32
|
On Mon, Sep 27, 2010 at 4:17 PM, Adam Retter <ad...@ex...> wrote: > At present a lot of the operations around permissions are restricted > to users in the DBA group. This is a artificial restriction that we > have imposed to try and keep a high level of security. I think that > this is a legacy, which in fairness was required, before Dmitriy's > excellent work to modernise and massively improve the security > architecture in eXist-db. > > However, I have two use cases (and there are probably others), whereby > I need to decompose the security architecture in eXist-db further to > allow us to build good web applications, where security can be managed > by appropriately by authorised and authenticated users. > > Use Case 1 > ---------------- > A user creates a group, and then later wishes to remove the group. > > Problem - At present anyone can create a group, BUT only users in the > DBA group can delete a group. It is undesirable to make all users DBA > as this gives them complete control over the running eXist-db > instance. > > > Use Case 2 > ---------------- > A user creates a group, and then needs to be able to invite other > users into his group for the purposes of sharing data. > > Problem - At present anyone can create a group, BUT only users in the > DBA group can add a user to a group. > > > > Proposed Solution > -------------------------- > Introduce the concept of ownership of a groups. The user who creates a > group, is the owner of that group. > > e.g. If the user "User A" creates a group "Group 1", he is the owner > of the group "Group 1". > 1) "User A" can add any other user to "Group 1", because he is the > owner of that group. > 2) Any user can remove themselves from any group they choose - I > cannot think of a case where downgrading a users rights prevents a > security risk. This is the users right! > We must think in different strategies: access grant or denied. Very often, better to deny access than grant, so removing must be limited to group's managres only. 3) "User A" can also delete "Group 1" when he choose because he is the > owner of that group. Again this is a case of downgrading users rights. > > Thanks Adam. > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > -- Dmitriy Shabanov |
From: Chris T. <chr...@gm...> - 2010-09-27 12:19:43
|
Unless membership in a group represents a restriction in the user's rights then self-removal can never increase the user's rights and so would seem to be permitted by the principle that no action by a user can increase their rights, only leave them the same or less. Chris On Sep 27, 2010, at 5:49 PM, Dmitriy Shabanov wrote: > 2) Any user can remove themselves from any group they choose - I > cannot think of a case where downgrading a users rights prevents a > security risk. This is the users right! > > We must think in different strategies: access grant or denied. Very often, better to deny access than grant, so removing must be limited to group's managres only. > |
From: Adam R. <ad...@ex...> - 2010-09-27 12:27:59
|
> We must think in different strategies: access grant or denied. Very often, > better to deny access than grant, so removing must be limited to group's > managres only. >> >> 3) "User A" can also delete "Group 1" when he choose because he is the >> owner of that group. Again this is a case of downgrading users rights. I disagree. If you own the group, then you can choose to the group as you wish. However there could be the option of co-owners as suggested by Chris Tomlinson - this is quite a common requirement in my experience also. -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Dmitriy S. <sha...@gm...> - 2010-09-27 13:43:43
|
On Mon, Sep 27, 2010 at 5:27 PM, Adam Retter <ad...@ex...> wrote: > > We must think in different strategies: access grant or denied. Very > often, > > better to deny access than grant, so removing must be limited to group's > > managres only. > >> > >> 3) "User A" can also delete "Group 1" when he choose because he is the > >> owner of that group. Again this is a case of downgrading users rights. > > I disagree. If you own the group, then you can choose to the group as > you wish. However there could be the option of co-owners as suggested > by Chris Tomlinson - this is quite a common requirement in my > experience also. > I did commit on: >2) Any user can remove themselves from any group they choose - I >cannot think of a case where downgrading a users rights prevents a >security risk. This is the users right! I did mail before, we must agree on terms we going to use. 'owner' is quite good, but limited. My offer: group's 'manager' (can change members list & permissions for group, it can be 2 different roles ) & 'member' (use group's permissions). It simple to see that there can be person that can manage, but have no access for resources. -- Dmitriy Shabanov |
From: Adam R. <ad...@ex...> - 2010-09-27 15:12:19
|
>>2) Any user can remove themselves from any group they choose - I >>cannot think of a case where downgrading a users rights prevents a >>security risk. This is the users right! > I did mail before, we must agree on terms we going to use. 'owner' is quite > good, but limited. My offer: group's 'manager' Owner or manager really makes no difference to me. In English it would seem to me that 'owner' is the more accurate and succinct term. > (can change members list & > permissions for group, it can be 2 different roles ) & 'member' (use group's > permissions). It simple to see that there can be person that can manage, but > have no access for resources. I am not clear on why a group would have 'permissions'? Surely collections and resources have permissions in terms of owner and group, but not the group object itself. -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Evgeny G. <gaz...@gm...> - 2010-09-27 15:23:10
|
Just group/accout object is resource too and already have permissions! -- Evgeny |
From: Dannes W. <da...@ex...> - 2010-09-27 16:21:00
|
On 27 Sep 2010, at 17:12 , Adam Retter wrote: > I am not clear on why a group would have 'permissions'? Surely > collections and resources have permissions in terms of owner and > group, but not the group object itself. Probably we want to have a look at the unix permissions model..... Kind regards Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Adam R. <ad...@ex...> - 2010-09-27 16:22:48
|
On 27 September 2010 17:20, Dannes Wessels <da...@ex...> wrote: > > On 27 Sep 2010, at 17:12 , Adam Retter wrote: > > I am not clear on why a group would have 'permissions'? Surely > collections and resources have permissions in terms of owner and > group, but not the group object itself. > > Probably we want to have a look at the unix permissions model..... Why? I am still not clear on why a group would have permissions itself? > Kind regards > Dannes > -- > eXist-db Native XML Database - http://exist-db.org > Join us on linked-in: http://www.linkedin.com/groups?gid=35624 > > > > > > > > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Dannes W. <da...@ex...> - 2010-09-27 17:33:59
|
I guess in the unix model, it is impossible for a normal user to assign other groups to a resource. On 27 Sep 2010, at 18:22 , Adam Retter wrote: >> Probably we want to have a look at the unix permissions model..... > > Why? I am still not clear on why a group would have permissions itself? Kind regards Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: José M. F. G. <jm...@us...> - 2010-09-27 17:55:51
|
Maybe this can be interesting for you, because it describes UNIX group management when a UNIX group has an administrator. http://linux.about.com/library/cmd/blcmdl1_gpasswd.htm On 27/09/10 19:33, Dannes Wessels wrote: > I guess in the unix model, it is impossible for a normal user to assign other groups to a resource. > > On 27 Sep 2010, at 18:22 , Adam Retter wrote: > >>> Probably we want to have a look at the unix permissions model..... >> >> Why? I am still not clear on why a group would have permissions itself? > > Kind regards > > Dannes > > -- > eXist-db Native XML Database - http://exist-db.org > Join us on linked-in: http://www.linkedin.com/groups?gid=35624 > > > > > > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > > > > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development -- "La violencia es el último recurso del incompetente" - Salvor Hardin en "La Fundación" de Isaac Asimov "Premature optimization is the root of all evil." - Donald Knuth José María Fernández González e-mail: jos...@gm... |
From: Dmitriy S. <sha...@gm...> - 2010-09-27 16:23:45
|
On Mon, Sep 27, 2010 at 8:12 PM, Adam Retter <ad...@ex...> wrote: > >>2) Any user can remove themselves from any group they choose - I > >>cannot think of a case where downgrading a users rights prevents a > >>security risk. This is the users right! > > I did mail before, we must agree on terms we going to use. 'owner' is > quite > > good, but limited. My offer: group's 'manager' > > Owner or manager really makes no difference to me. In English it would > seem to me that 'owner' is the more accurate and succinct term. > By limited I did mean that there are two possible roles: memeber list manager (hope that's clear) & group's permisions manager (change resource permissions, that change group access level). I'm happy to have only group's 'owner' if there only one role under this, but I did show: it's multi-roles defenation, that's why it bad one. > > (can change members list & > > permissions for group, it can be 2 different roles ) & 'member' (use > group's > > permissions). It simple to see that there can be person that can manage, > but > > have no access for resources. > > > I am not clear on why a group would have 'permissions'? Surely > collections and resources have permissions in terms of owner and > group, but not the group object itself. > Mirror your view and you will get my one. -- Dmitriy Shabanov |
From: Adam R. <ad...@ex...> - 2010-09-27 16:26:28
|
>> Owner or manager really makes no difference to me. In English it would >> seem to me that 'owner' is the more accurate and succinct term. > > By limited I did mean that there are two possible roles: memeber > list manager (hope that's clear) & group's permisions manager (change > resource permissions, that change group access level). I'm happy to have > only group's 'owner' if there only one role under this, but I did show: it's > multi-roles defenation, that's why it bad one. Okay I think I am not understanding something, because I can only see that there is one role here? >> >> > (can change members list & >> > permissions for group, it can be 2 different roles ) & 'member' (use >> > group's >> > permissions). It simple to see that there can be person that can manage, >> > but >> > have no access for resources. >> >> >> I am not clear on why a group would have 'permissions'? Surely >> collections and resources have permissions in terms of owner and >> group, but not the group object itself. > > Mirror your view and you will get my one. Can we teleconf about this, as I am afraid that I am not following you. When is good for you Dmitriy? Cheers Adam. > -- > Dmitriy Shabanov > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Dmitriy S. <sha...@gm...> - 2010-09-27 16:33:41
|
On Mon, Sep 27, 2010 at 9:26 PM, Adam Retter <ad...@ex...> wrote: > >> Owner or manager really makes no difference to me. In English it would > >> seem to me that 'owner' is the more accurate and succinct term. > > > > By limited I did mean that there are two possible roles: memeber > > list manager (hope that's clear) & group's permisions manager (change > > resource permissions, that change group access level). I'm happy to have > > only group's 'owner' if there only one role under this, but I did show: > it's > > multi-roles defenation, that's why it bad one. > > Okay I think I am not understanding something, because I can only see > that there is one role here? > > >> > >> > (can change members list & > >> > permissions for group, it can be 2 different roles ) & 'member' (use > >> > group's > >> > permissions). It simple to see that there can be person that can > manage, > >> > but > >> > have no access for resources. > >> > >> > >> I am not clear on why a group would have 'permissions'? Surely > >> collections and resources have permissions in terms of owner and > >> group, but not the group object itself. > > > > Mirror your view and you will get my one. > > Can we teleconf about this, as I am afraid that I am not following > you. When is good for you Dmitriy? I did try to contact you today, but ... So, tomorrow 20:00 my time? -- Dmitriy Shabanov |
From: Adam R. <ad...@ex...> - 2010-09-27 16:41:24
|
> I did try to contact you today, but ... So, tomorrow 20:00 my time? Cant do that as its the W3C XQuery/XSL WG teleconf, which I think your involved in as well arent you? I can do anytime in the day before that though... -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Dannes W. <da...@ex...> - 2010-09-27 19:36:56
|
Hi, On 27 Sep 2010, at 15:43 , Dmitriy Shabanov wrote: > I did mail before, we must agree on terms we going to use. 'owner' is quite good, but limited. My offer: group's 'manager' (can change members list & permissions for group, it can be 2 different roles ) & 'member' (use group's permissions). It simple to see that there can be person that can manage, but have no access for resources. by any chance, what happens if a group is removed (having a unique internal id) and a new group is added? Will the same id be reused internally? Kind regards Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Dmitriy S. <sha...@gm...> - 2010-09-28 14:54:34
|
On Tue, Sep 28, 2010 at 12:36 AM, Dannes Wessels <da...@ex...>wrote: > Hi, > > On 27 Sep 2010, at 15:43 , Dmitriy Shabanov wrote: > > I did mail before, we must agree on terms we going to use. 'owner' is quite > good, but limited. My offer: group's 'manager' (can change members list & > permissions for group, it can be 2 different roles ) & 'member' (use group's > permissions). It simple to see that there can be person that can manage, but > have no access for resources. > > > by any chance, what happens if a group is removed (having a unique internal > id) and a new group is added? Will the same id be reused internally? > > Current design: unique id to all groups. Example: - add group 'A' (get id 1); - remove group 'A' (move group description file to 'removed' collection, if I remember correct); - add group 'A' (get id 2); -- Dmitriy Shabanov |
From: Thomas W. <tho...@gm...> - 2010-09-28 08:42:30
|
On 27 September 2010 16:12, Adam Retter <ad...@ex...> wrote: > >>2) Any user can remove themselves from any group they choose - I > >>cannot think of a case where downgrading a users rights prevents a > >>security risk. This is the users right! > > I did mail before, we must agree on terms we going to use. 'owner' is > quite > > good, but limited. My offer: group's 'manager' > > Owner or manager really makes no difference to me. In English it would > seem to me that 'owner' is the more accurate and succinct term. > > > (can change members list & > > permissions for group, it can be 2 different roles ) & 'member' (use > group's > > permissions). It simple to see that there can be person that can manage, > but > > have no access for resources. > > > I am not clear on why a group would have 'permissions'? Surely > collections and resources have permissions in terms of owner and > group, but not the group object itself. Adam, I think Dmitriy is proposing a model where there is a clear separation between being a member of a group and managing the group itself. I quite like the idea and it takes care of a common case from the practice. Example: An admin who manages the group of CEO users does not need to have access to the confidential reports in a collection, available to the members of this group. When we discuss eXist security matters I think it is high time to start looking at it from a slightly bigger perspective. Imagine a company of 1000 employees where to have one admin user that does it all is nor neither possible nor practical . There will be teams of admins dealing with variety of jobs across the teams and departments. Thomas > > -- > Adam Retter > > eXist Developer > { United Kingdom } > ad...@ex... > irc://irc.freenode.net/existdb > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > |
From: Adam R. <ad...@ex...> - 2010-09-28 08:47:47
|
On 28 September 2010 09:42, Thomas White <tho...@gm...> wrote: > On 27 September 2010 16:12, Adam Retter <ad...@ex...> wrote: >> >> >>2) Any user can remove themselves from any group they choose - I >> >>cannot think of a case where downgrading a users rights prevents a >> >>security risk. This is the users right! >> > I did mail before, we must agree on terms we going to use. 'owner' is >> > quite >> > good, but limited. My offer: group's 'manager' >> >> Owner or manager really makes no difference to me. In English it would >> seem to me that 'owner' is the more accurate and succinct term. >> >> > (can change members list & >> > permissions for group, it can be 2 different roles ) & 'member' (use >> > group's >> > permissions). It simple to see that there can be person that can manage, >> > but >> > have no access for resources. >> >> >> I am not clear on why a group would have 'permissions'? Surely >> collections and resources have permissions in terms of owner and >> group, but not the group object itself. > > > Adam, I think Dmitriy is proposing a model where there is a clear separation > between being a member of a group and managing the group itself. I quite > like the idea and it takes care of a common case from the practice. > > Example: An admin who manages the group of CEO users does not need to have > access to the confidential reports in a collection, available to the members > of this group. Dmitriy is that the case? If so you explanation has made this much more understandable for me, thanks :-) Of course this is what CEO's want, but in my experience the admin can always access absolutely anything if he or she wants to ;-) > When we discuss eXist security matters I think it is high time to start > looking at it from a slightly bigger perspective. Imagine a company of 1000 > employees where to have one admin user that does it all is nor neither > possible nor practical . There will be teams of admins dealing with variety > of jobs across the teams and departments. > > Thomas > > > >> >> -- >> Adam Retter >> >> eXist Developer >> { United Kingdom } >> ad...@ex... >> irc://irc.freenode.net/existdb >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> 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 |
From: Dmitriy S. <sha...@gm...> - 2010-09-28 15:04:59
|
On Tue, Sep 28, 2010 at 1:47 PM, Adam Retter <ad...@ex...> wrote: > On 28 September 2010 09:42, Thomas White <tho...@gm...> wrote: > > On 27 September 2010 16:12, Adam Retter <ad...@ex...> wrote: > >> > >> >>2) Any user can remove themselves from any group they choose - I > >> >>cannot think of a case where downgrading a users rights prevents a > >> >>security risk. This is the users right! > >> > I did mail before, we must agree on terms we going to use. 'owner' is > >> > quite > >> > good, but limited. My offer: group's 'manager' > >> > >> Owner or manager really makes no difference to me. In English it would > >> seem to me that 'owner' is the more accurate and succinct term. > >> > >> > (can change members list & > >> > permissions for group, it can be 2 different roles ) & 'member' (use > >> > group's > >> > permissions). It simple to see that there can be person that can > manage, > >> > but > >> > have no access for resources. > >> > >> > >> I am not clear on why a group would have 'permissions'? Surely > >> collections and resources have permissions in terms of owner and > >> group, but not the group object itself. > > > > > > Adam, I think Dmitriy is proposing a model where there is a clear > separation > > between being a member of a group and managing the group itself. I quite > > like the idea and it takes care of a common case from the practice. > > > > Example: An admin who manages the group of CEO users does not need to > have > > access to the confidential reports in a collection, available to the > members > > of this group. > > Dmitriy is that the case? If so you explanation has made this much > more understandable for me, thanks :-) > Eхplanation is my weakness :-) Of course this is what CEO's want, but in my experience the admin can > always access absolutely anything if he or she wants to ;-) I'm admin, but I don't have time to do all staff after all. So, it's more of job sharing ... > > When we discuss eXist security matters I think it is high time to start > > looking at it from a slightly bigger perspective. Imagine a company of > 1000 > > employees where to have one admin user that does it all is nor neither > > possible nor practical . There will be teams of admins dealing with > variety > > of jobs across the teams and departments. > > > > Thomas > > > > > > > >> > >> -- > >> Adam Retter > >> > >> eXist Developer > >> { United Kingdom } > >> ad...@ex... > >> irc://irc.freenode.net/existdb > >> > >> > >> > ------------------------------------------------------------------------------ > >> Start uncovering the many advantages of virtual appliances > >> and start using them to simplify application deployment and > >> accelerate your shift to cloud computing. > >> http://p.sf.net/sfu/novell-sfdev2dev > >> _______________________________________________ > >> 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 > -- Dmitriy Shabanov |
From: Peter C. <pet...@me...> - 2010-09-30 13:24:49
|
Can I point readers towards Microsoft's security model for NTFS and Active Directory (which is in turn based on VAX/VMS)? It's simple in concept and extremely flexible. The extended permissions models in modern UNIXes are similar. There are: - Objects that require securing; - Rights that a principal may have over an object (these my be different for each type of object); - One access control list (ACL) for each object, containing a list of tuples of <principal, right, allow/deny>. I think what we're discussing here is what the rights should be, and whether there are any that cannot / should not be taken out of the ACL. From my experience, after writing such a permissions system for a virtual learning system, I'd say that all combinations of things in the ACL should be allowed. Incidentally, the NTFS version of auditing is also extremely flexible and worth a look. Finally, the designers have gone to considerable lengths to ensure that an administrator cannot completely hide that they've taken some underhand action, although they can hide what that action was. - Peter On 28 September 2010 16:04, Dmitriy Shabanov <sha...@gm...> wrote: > > > On Tue, Sep 28, 2010 at 1:47 PM, Adam Retter <ad...@ex...> wrote: > >> On 28 September 2010 09:42, Thomas White <tho...@gm...> wrote: >> > On 27 September 2010 16:12, Adam Retter <ad...@ex...> wrote: >> >> >> >> >>2) Any user can remove themselves from any group they choose - I >> >> >>cannot think of a case where downgrading a users rights prevents a >> >> >>security risk. This is the users right! >> >> > I did mail before, we must agree on terms we going to use. 'owner' is >> >> > quite >> >> > good, but limited. My offer: group's 'manager' >> >> >> >> Owner or manager really makes no difference to me. In English it would >> >> seem to me that 'owner' is the more accurate and succinct term. >> >> >> >> > (can change members list & >> >> > permissions for group, it can be 2 different roles ) & 'member' (use >> >> > group's >> >> > permissions). It simple to see that there can be person that can >> manage, >> >> > but >> >> > have no access for resources. >> >> >> >> >> >> I am not clear on why a group would have 'permissions'? Surely >> >> collections and resources have permissions in terms of owner and >> >> group, but not the group object itself. >> > >> > >> > Adam, I think Dmitriy is proposing a model where there is a clear >> separation >> > between being a member of a group and managing the group itself. I quite >> > like the idea and it takes care of a common case from the practice. >> > >> > Example: An admin who manages the group of CEO users does not need to >> have >> > access to the confidential reports in a collection, available to the >> members >> > of this group. >> >> Dmitriy is that the case? If so you explanation has made this much >> more understandable for me, thanks :-) >> > > Eхplanation is my weakness :-) > > Of course this is what CEO's want, but in my experience the admin can >> always access absolutely anything if he or she wants to ;-) > > > I'm admin, but I don't have time to do all staff after all. So, it's more > of job sharing ... > > >> > When we discuss eXist security matters I think it is high time to start >> > looking at it from a slightly bigger perspective. Imagine a company of >> 1000 >> > employees where to have one admin user that does it all is nor neither >> > possible nor practical . There will be teams of admins dealing with >> variety >> > of jobs across the teams and departments. >> > >> > Thomas >> > >> > >> > >> >> >> >> -- >> >> Adam Retter >> >> >> >> eXist Developer >> >> { United Kingdom } >> >> ad...@ex... >> >> irc://irc.freenode.net/existdb >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Start uncovering the many advantages of virtual appliances >> >> and start using them to simplify application deployment and >> >> accelerate your shift to cloud computing. >> >> http://p.sf.net/sfu/novell-sfdev2dev >> >> _______________________________________________ >> >> 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 >> > > > > -- > Dmitriy Shabanov > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development > > |