Re: [xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

[Marius Dumitru Florea]

On Tue, Jan 17, 2017 at 5:54 PM, 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.
>

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
>

Re: [xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

[Sergiu Dumitriu]

Oh, forgot this one:

system::migrator(R8XWIKI12345)
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  ? false : 
> 
> 
> 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

Re: [xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

[Sergiu Dumitriu]

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  ? false : 


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

Re: [xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

[Thomas Mortagne]

On Tue, Jan 17, 2017 at 5:19 PM, Denis Gervalle  wrote:
> On Tue, Jan 17, 2017 at 5:08 PM, Thomas Mortagne  
> wrote: On Tue, Jan 17, 2017 at 5:02 PM, Vincent Massol  
> wrote:
>> Hi Thomas,
>>
>>> On 17 Jan 2017, at 16:54, 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 ?
>>
>> 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

Re: [xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

[Denis Gervalle]

On Tue, Jan 17, 2017 at 5:08 PM, Thomas Mortagne  
wrote: On Tue, Jan 17, 2017 at 5:02 PM, Vincent Massol  
wrote:
> Hi Thomas,
>
>> On 17 Jan 2017, at 16:54, 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 ?
>
> 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

Re: [xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

[Vincent Massol]

Hi Thomas,

> On 17 Jan 2017, at 16:54, 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 ?

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

Re: [xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

[Thomas Mortagne]

On Tue, Jan 17, 2017 at 5:02 PM, Vincent Massol  wrote:
> Hi Thomas,
>
>> On 17 Jan 2017, at 16:54, 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 ?
>
> 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

[xwiki-devs] [PROPOSAL] Make extension pages author superadmin when current user have programming right

[Thomas Mortagne]

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

Re: [xwiki-devs] [xwiki-users] [ANN] First version of the XWiki docker packaging

[Vincent Massol]

Hi Miroslav,

> On 16 Jan 2017, at 23:42, Miroslav Galajda  wrote:
> 
> Hi, all that's great to hear. The docker is getting more and more popular
> :-)
> 
> Recently, I have "dockerized" XWiki v8.4 hosted in Tomcat and backed by
> OracleXE for my testing purposes.

This is great, the more the merrier! :)

FTR there are currently 29 repos with XWiki images on docker hub 
(https://hub.docker.com/search/?isAutomated=0=0=1=0=xwiki=0).
 This makes it not easy for users to know why one to use. This is why I thought 
it would be important to have some “official” docker images from the xwiki open 
source project maintained by the xwiki devs.

I think the next step is to add images for postgresql and oracle since both are 
supported DBs. What I’m trying to figure out is how to share source files for 
the Dockerfiles. Using “-f” should work but it’s not supported by automated 
builds o dockerhub yet (https://github.com/docker/hub-feedback/issues/292). 
Help is most welcome! :)

Thanks
-Vincent

> I will definitely try your version, it
> seems more komplex and more configurable than mine :-)
> 
> Mirec
> 
> On 16 January 2017 at 22:36, Vincent Massol  wrote:
> 
>> Hi Craig,
>> 
>>> On 16 Jan 2017, at 21:51, Craig Wright  wrote:
>>> 
>>> Hi Vincent,
>>> 
>>> This is great, and if it had been out two weeks ago I would have used it
>> as the basis for my installation! ;D
>>> 
>>> I can’t promise to check it out in the near-term future but when I get a
>> chance to revisit the install method, I will check it out.
>> 
>> Cool
>> 
>>> When you release a new version, do you plan on pushing that out as a new
>> Docker image, or will you upgrade-in-place in the container? I assume the
>> former.
>> 
>> Yep, I’ll push new images.
>> 
>> Thanks
>> -Vincent
>> 
>>> Thanks,
>>> Craig
>>> 
>>> 
 On Jan 16, 2017, at 12:33 PM, Vincent Massol 
>> wrote:
 
 Note that my assumption so far has been to provide a production-ready
>> Dockerized XWiki. This is not meant to be a demo container to test out
>> XWiki.
 
 * This is for example why I’ve used Debian:jessy as the base imagine
>> and not alpine for example. Another option to slim it down would be to use
>> https://hub.docker.com/r/tklx/base/ but I’ve preferred to use what you’d
>> use in production.
 * This is also why I’m using docker-compose and have several separate
>> containers for the DB and for XWiki/Tomcat.
 
 Thanks
 -Vìncent
 
> On 16 Jan 2017, at 18:37, Vincent Massol  wrote:
> 
> Hi everyone,
> 
> I’ve started a first version of a XWiki docker packaging at
>> https://github.com/xwiki-contrib/docker-xwiki and I’ve created an
>> automated build on DockerHub at https://hub.docker.com/u/xwiki/. The goal
>> is to provide an official packaging done by the XWiki dev team.
> 
> Since I’m a recent user of Docker I’m sure I’ve made plenty of
>> mistakes and not following some best practices, even though I’ve tried my
>> best to do that ;)
> 
> So it would be great if:
> * Some users could try it out and let me know how it works
> * Users could tell me what they’d expect in term of setup from a
>> docker distribution.
> * Some Docker experts review my code and let me know what I should
>> improve!
> 
> After I receive some confirmation that it works well-enough, my goal
>> is to document it as an official way of installing xwiki on xwiki.org.
> 
> Feel free to create jiras for ideas and bugs at
>> http://jira.xwiki.org/browse/XDOCKER.
> 
> Thanks a lot!
> -Vincent
> 
> PS: Note that I’m sure some will want a different DB, such as
>> postgreSQL for example. That should be easy to do. Pull request accepted! :)
> 
 
>>> 
>> 
>>