[xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right
Hi devs, I'm thinking since a long time that maybe we should automatically make superadmin the author of the pages when installing a XAR as long as the current user (and current author) have programming right (i.e. has the same rights than superadmin when the extension is installed). I don't really see anything against it these days and it's easy to do so why not. Basically the goal is to reduce the possibility to break extensions when you play with existing users/groups/rights. Common user case being to get rid of some old adminsys leaving the company. WDYT ? Note: to be complete we could imagine the same kind of thing for admin user but that require the introduction of a virtual admin right user like superadmin is a vitual programming right user. But let's not discuss too many thing at once. -- Thomas Mortagne
Hi Thomas,
On 17 Jan 2017, at 16:54, Thomas Mortagne <[email protected]> wrote:
Hi devs,
I'm thinking since a long time that maybe we should automatically make superadmin the author of the pages when installing a XAR as long as the current user (and current author) have programming right (i.e. has the same rights than superadmin when the extension is installed). I don't really see anything against it these days and it's easy to do so why not.
Basically the goal is to reduce the possibility to break extensions when you play with existing users/groups/rights. Common user case being to get rid of some old adminsys leaving the company.
WDYT ?
Why not. However I haven’t thought enough about it but right now the downside I see is the loss of accountability/tracability. It’s interesting to know what user has installed a given page. Using superadmin would loose this info. BTW and related to this, I’d prefer to have a System user instead of using superadmin. The rationale is that super admin is user and you can log with it whereas System wouldn’t be a user that you can log with. It would represent a change made by the system. This could be another discussion but I thought I would mention it here to be complete. Thanks -Vincent
Note: to be complete we could imagine the same kind of thing for admin user but that require the introduction of a virtual admin right user like superadmin is a vitual programming right user. But let's not discuss too many thing at once.
-- Thomas Mortagne
On Tue, Jan 17, 2017 at 5:02 PM, Vincent Massol <[email protected]> wrote:
Hi Thomas,
On 17 Jan 2017, at 16:54, Thomas Mortagne <[email protected]> wrote:
Hi devs,
I'm thinking since a long time that maybe we should automatically make superadmin the author of the pages when installing a XAR as long as the current user (and current author) have programming right (i.e. has the same rights than superadmin when the extension is installed). I don't really see anything against it these days and it's easy to do so why not.
Basically the goal is to reduce the possibility to break extensions when you play with existing users/groups/rights. Common user case being to get rid of some old adminsys leaving the company.
WDYT ?
Why not. However I haven’t thought enough about it but right now the downside I see is the loss of accountability/tracability. It’s interesting to know what user has installed a given page. Using superadmin would loose this info.
You can know wo installed the extension so it reduce a bit the history problem.
BTW and related to this, I’d prefer to have a System user instead of using superadmin. The rationale is that super admin is user and you can log with it whereas System wouldn’t be a user that you can log with. It would represent a change made by the system. This could be another discussion but I thought I would mention it here to be complete.
The main issue is that it's not so easy to introduce new virtual users without potentially colliding with some existing user somewhere. That's the issue with possible virtual admin user too.
Thanks -Vincent
Note: to be complete we could imagine the same kind of thing for admin user but that require the introduction of a virtual admin right user like superadmin is a vitual programming right user. But let's not discuss too many thing at once.
-- Thomas Mortagne
-- Thomas Mortagne
On Tue, Jan 17, 2017 at 5:08 PM, Thomas Mortagne <[email protected]> wrote: On Tue, Jan 17, 2017 at 5:02 PM, Vincent Massol <[email protected]> wrote:
Hi Thomas,
On 17 Jan 2017, at 16:54, Thomas Mortagne <[email protected]> wrote:
Hi devs,
I'm thinking since a long time that maybe we should automatically make superadmin the author of the pages when installing a XAR as long as the current user (and current author) have programming right (i.e. has the same rights than superadmin when the extension is installed). I don't really see anything against it these days and it's easy to do so why not.
Basically the goal is to reduce the possibility to break extensions when you play with existing users/groups/rights. Common user case being to get rid of some old adminsys leaving the company.
WDYT ?
Why not. However I haven’t thought enough about it but right now the downside I see is the loss of accountability/tracability. It’s interesting to know what user has installed a given page. Using superadmin would loose this info.
You can know wo installed the extension so it reduce a bit the history problem. Couldn’t we keep the author as is, and just apply this to the content author ? Wouldn’t this be sufficient for our purpose ?
BTW and related to this, I’d prefer to have a System user instead of using superadmin. The rationale is that super admin is user and you can log with it whereas System wouldn’t be a user that you can log with. It would represent a change made by the system. This could be another discussion but I thought I would mention it here to be complete.
The main issue is that it's not so easy to introduce new virtual users without potentially colliding with some existing user somewhere. That's the issue with possible virtual admin user too.
Thanks -Vincent
Note: to be complete we could imagine the same kind of thing for admin user but that require the introduction of a virtual admin right user like superadmin is a vitual programming right user. But let's not discuss too many thing at once.
-- Thomas Mortagne
-- Thomas Mortagne -- Denis Gervalle SOFTEC sa - CEO
On Tue, Jan 17, 2017 at 5:19 PM, Denis Gervalle <[email protected]> wrote:
On Tue, Jan 17, 2017 at 5:08 PM, Thomas Mortagne <[email protected]> wrote: On Tue, Jan 17, 2017 at 5:02 PM, Vincent Massol <[email protected]> wrote:
Hi Thomas,
On 17 Jan 2017, at 16:54, Thomas Mortagne <[email protected]> wrote:
Hi devs,
I'm thinking since a long time that maybe we should automatically make superadmin the author of the pages when installing a XAR as long as the current user (and current author) have programming right (i.e. has the same rights than superadmin when the extension is installed). I don't really see anything against it these days and it's easy to do so why not.
Basically the goal is to reduce the possibility to break extensions when you play with existing users/groups/rights. Common user case being to get rid of some old adminsys leaving the company.
WDYT ?
Why not. However I haven’t thought enough about it but right now the downside I see is the loss of accountability/tracability. It’s interesting to know what user has installed a given page. Using superadmin would loose this info.
You can know wo installed the extension so it reduce a bit the history problem. Couldn’t we keep the author as is, and just apply this to the content author ? Wouldn’t this be sufficient for our purpose ?
Not because all wiki components (wiki macros, wiki components, translations, etc.) use author.
BTW and related to this, I’d prefer to have a System user instead of using superadmin. The rationale is that super admin is user and you can log with it whereas System wouldn’t be a user that you can log with. It would represent a change made by the system. This could be another discussion but I thought I would mention it here to be complete.
The main issue is that it's not so easy to introduce new virtual users without potentially colliding with some existing user somewhere. That's the issue with possible virtual admin user too.
Thanks -Vincent
Note: to be complete we could imagine the same kind of thing for admin user but that require the introduction of a virtual admin right user like superadmin is a vitual programming right user. But let's not discuss too many thing at once.
-- Thomas Mortagne
-- Thomas Mortagne -- Denis Gervalle SOFTEC sa - CEO
-- Thomas Mortagne
I'd like something more complex, and more flexible at the same time. Instead of having simple user names, I'd like to see a more powerful "principal" mechanism in XWiki, with roles and delegates. A first usecase is separating users and their admin privileges. Instead of automatically granting admin privileges to users all the time, there should be a "sudo" equivalent. This gives a bit of safety against cross-XYZ / XYZ-injection attacks, since normally a user browsing the wiki wouldn't have admin/scripting/programming privileges, unless manually entering "admin mode". There wouldn't be an "Admin" user anymore, just users that can switch to "Administrator" mode, and this would be recorded as (for example): delegate::role(user::xwiki:Users.jdoe|role::administrator) delegate::role(user::xwiki:Users.jdoe|role::developer) When asking for the current principal, this is what would be returned, and stored as the author of a document after a change. We still know that it was "jdoe" performing the changes. Checking for scripting rights later is done both on the source user (if it's denied) and on the target role (if it's allowed). return <is the source denied> ? false : <is the target allowed> Another usecase would be an admin logging in as another user, to experience what the user sees without having to ask (or temporarily change) the user's password. Jira has this feature, and it's very useful for debugging rights. This can also be recorded as a delegate principal: delegate::su(user::xwiki:Users.tanderson|user::xwiki:Users.neo) A third usecase, which doesn't make much sense in the base XWiki, but which is needed in more complex applications where there's a more pronounced emphasis on groups, is when a group member acts on behalf of the group: delegate::member(user::xwiki:Users.padams|group::xwiki.Groups.Pediatricians) Here, Patch Adams is acting on behalf of the group of pediatricians when writing a press release. Another one: more info about guests. Instead of pretending that there's only one special "XWikiGuest" user, we can record more information: role::guest(ip:192.168.0.123|visit:42) Later, we can see everything this guest did. That's on the "who am I" end, but this also extends to "who should I be" part, i.e. setting rights for special roles. allow admin for role::administrator allow scripting for role::developer deny scripting for group::xwiki:Groups.TheBadGuys allow delete for role::creator deny view for role::guest allow sudo for group::xwiki:Groups.Administrators deny vote for karma::lt(100) The last one shows that the types of principals can be customized by new component implementations, and evaluating if the current principal matches a target principal can be more complex than what's there now, "is the same user" or "is member of a group". Also, the rights should be extensible, right now adding a new right is not impossible, but not very easy either. I've been working on designing and implementing this on and off for the past year, but there's still a long way to go. Just some food for thought, -0 for the proposed change. On 01/17/2017 10:54 AM, Thomas Mortagne wrote:
Hi devs,
I'm thinking since a long time that maybe we should automatically make superadmin the author of the pages when installing a XAR as long as the current user (and current author) have programming right (i.e. has the same rights than superadmin when the extension is installed). I don't really see anything against it these days and it's easy to do so why not.
Basically the goal is to reduce the possibility to break extensions when you play with existing users/groups/rights. Common user case being to get rid of some old adminsys leaving the company.
WDYT ?
Note: to be complete we could imagine the same kind of thing for admin user but that require the introduction of a virtual admin right user like superadmin is a vitual programming right user. But let's not discuss too many thing at once.
-- Sergiu Dumitriu http://purl.org/net/sergiu
Oh, forgot this one: system::migrator(R80000XWIKI12345) system::extension-upgrade(org.xwiki.contrib:cool-app:1.2.3) system::password-reset(ip:1.2.3.4) On 01/17/2017 02:14 PM, Sergiu Dumitriu wrote:
I'd like something more complex, and more flexible at the same time. Instead of having simple user names, I'd like to see a more powerful "principal" mechanism in XWiki, with roles and delegates.
A first usecase is separating users and their admin privileges. Instead of automatically granting admin privileges to users all the time, there should be a "sudo" equivalent. This gives a bit of safety against cross-XYZ / XYZ-injection attacks, since normally a user browsing the wiki wouldn't have admin/scripting/programming privileges, unless manually entering "admin mode". There wouldn't be an "Admin" user anymore, just users that can switch to "Administrator" mode, and this would be recorded as (for example):
delegate::role(user::xwiki:Users.jdoe|role::administrator) delegate::role(user::xwiki:Users.jdoe|role::developer)
When asking for the current principal, this is what would be returned, and stored as the author of a document after a change. We still know that it was "jdoe" performing the changes. Checking for scripting rights later is done both on the source user (if it's denied) and on the target role (if it's allowed).
return <is the source denied> ? false : <is the target allowed>
Another usecase would be an admin logging in as another user, to experience what the user sees without having to ask (or temporarily change) the user's password. Jira has this feature, and it's very useful for debugging rights. This can also be recorded as a delegate principal:
delegate::su(user::xwiki:Users.tanderson|user::xwiki:Users.neo)
A third usecase, which doesn't make much sense in the base XWiki, but which is needed in more complex applications where there's a more pronounced emphasis on groups, is when a group member acts on behalf of the group:
delegate::member(user::xwiki:Users.padams|group::xwiki.Groups.Pediatricians)
Here, Patch Adams is acting on behalf of the group of pediatricians when writing a press release.
Another one: more info about guests. Instead of pretending that there's only one special "XWikiGuest" user, we can record more information:
role::guest(ip:192.168.0.123|visit:42)
Later, we can see everything this guest did.
That's on the "who am I" end, but this also extends to "who should I be" part, i.e. setting rights for special roles.
allow admin for role::administrator allow scripting for role::developer deny scripting for group::xwiki:Groups.TheBadGuys allow delete for role::creator deny view for role::guest allow sudo for group::xwiki:Groups.Administrators deny vote for karma::lt(100)
The last one shows that the types of principals can be customized by new component implementations, and evaluating if the current principal matches a target principal can be more complex than what's there now, "is the same user" or "is member of a group". Also, the rights should be extensible, right now adding a new right is not impossible, but not very easy either.
I've been working on designing and implementing this on and off for the past year, but there's still a long way to go.
Just some food for thought, -0 for the proposed change.
On 01/17/2017 10:54 AM, Thomas Mortagne wrote:
Hi devs,
I'm thinking since a long time that maybe we should automatically make superadmin the author of the pages when installing a XAR as long as the current user (and current author) have programming right (i.e. has the same rights than superadmin when the extension is installed). I don't really see anything against it these days and it's easy to do so why not.
Basically the goal is to reduce the possibility to break extensions when you play with existing users/groups/rights. Common user case being to get rid of some old adminsys leaving the company.
WDYT ?
Note: to be complete we could imagine the same kind of thing for admin user but that require the introduction of a virtual admin right user like superadmin is a vitual programming right user. But let's not discuss too many thing at once.
-- Sergiu Dumitriu http://purl.org/net/sergiu
On Tue, Jan 17, 2017 at 5:54 PM, Thomas Mortagne <[email protected]> wrote:
Hi devs,
I'm thinking since a long time that maybe we should automatically make superadmin the author of the pages when installing a XAR as long as the current user (and current author) have programming right (i.e. has the same rights than superadmin when the extension is installed). I don't really see anything against it these days and it's easy to do so why not.
Basically the goal is to reduce the possibility to break extensions when you play with existing users/groups/rights. Common user case being to get rid of some old adminsys leaving the company.
The solution you propose looks more like a hack or workaround for the the problem you mentioned. I'm +0 ATM. Thanks, Marius
WDYT ?
Note: to be complete we could imagine the same kind of thing for admin user but that require the introduction of a virtual admin right user like superadmin is a vitual programming right user. But let's not discuss too many thing at once.
-- Thomas Mortagne
On Wed, Jan 18, 2017 at 7:10 AM, Marius Dumitru Florea <[email protected]> wrote:
On Tue, Jan 17, 2017 at 5:54 PM, Thomas Mortagne <[email protected]> wrote:
Hi devs,
I'm thinking since a long time that maybe we should automatically make superadmin the author of the pages when installing a XAR as long as the current user (and current author) have programming right (i.e. has the same rights than superadmin when the extension is installed). I don't really see anything against it these days and it's easy to do so why not.
Basically the goal is to reduce the possibility to break extensions when you play with existing users/groups/rights. Common user case being to get rid of some old adminsys leaving the company.
The solution you propose looks more like a hack or workaround for the the problem you mentioned. I'm +0 ATM.
The goal is not to discuss the way to fix this issue for good here. I'm just proposing to do this easy change (which I don't agree is a hack, you could argue that you expect the author of extension pages to be some system user) which among other things make this use case a lot less common.
Thanks, Marius
WDYT ?
Note: to be complete we could imagine the same kind of thing for admin user but that require the introduction of a virtual admin right user like superadmin is a vitual programming right user. But let's not discuss too many thing at once.
-- Thomas Mortagne
-- Thomas Mortagne
participants (5)
-
Denis Gervalle -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol