mavenized repo.xml

[duncdrum]

After running

$ mvn clean package

the xar's repo.xml contains two namespace declarations, WAI? The second one seems superfluous

xmlns="http://exist-db.org/xquery/repo" 
xmlns:repo="http://exist-db.org/xquery/repo"

it also adds permissions like this:

<permissions user="admin" password="" group="dba" mode="rw-rw-r--"/>

Why does the documentation app require app specific permissions? The default permissions seem superfluous for normal install and upgrade of the app. However on systems with an user named admin and with a different password things might trip up.

[adamretter]

1. Regards the namespaces, that is not a breaking issue. However, if you want it to look prettier, you would need to contact @claudius108 as he maintains the EXPath Pkg plugin for Maven. It is likely that that is what is generating that style of repo.xml

2. The permissions element is added because it is present in the xar-assembly.xml file. I have no idea why it is needed, I simply tried to recreate what was originally done when we previously used Ant to generate the repo.xml and Xar. It is quite possible that it is not needed...

[dizzzz]

with the permissions element you can create a user/group, set a password and default permissions... For many extensions make the functionality can be used by admin and anyone member of a certain group.

[duncdrum]

@dizzzz I know. My question was why would the documentation app that runs on every single instance of exist out there, require an app specific user on each one?

[joewiz]

@duncdrum I'm curious, with the <permissions> element deleted, who is the owner of the installed resources?

I ask because I always assumed, based on the documentation about the <permissions> element, that this element is mandatory. Its role is described as follows:

The permissions to use when uploading package contents. All resources and collections will be owned by the specified user and permissions will be changed to those given in mode. If the user does not exist, the deploy function will try to create it, using the password specified in attribute password.

Concerning permissions, the execute ("x") flag will be set automatically on all XQuery files in addition to the default permissions defined in the descriptor. For more control over permissions, use a post-install XQuery script (see element "finish" below).

I assumed, based on this, that the <permissions> element is mandatory, and so my practice for apps has always been to supply a dummy user name and group for each app, e.g., documentation-user and documentation-group. I really have no idea what happens if the <permissions> element is missing, so I'm curious about what really happens and whether this is "legal" to do?

[duncdrum]

@joewiz the clue lies in:

If the user does not exist, the deploy function will try to create it, using the password specified in attribute password.

If the app doesn't include this element, the permission of the user initiating the install are used as they should be. The app will fall under the permissions regime of the instance.

If there is an element, you add a new app specific user to every instance installing the app. The tei-publisher, actually makes good use of this. Not every app needs an app specific user and user group. Not that admin dbawould be very specific or clearly tied to documentation.

I think we should leave it up to dba's (whatever their username) to decide who can edit or update their local documentation installs, and if if should or should not belong to any groups. This certainly is legal since eXide's app generator doesn't create permissions unless you explicitly tell it to, and I have never encountered problems with apps without app specific permissions.

Mostly in terms of security, adding dummy users with empty passwords liberally to exist instances doesn't seem like good idea to me. Especially when they are not necessary.

[dizzzz]

Eeks... when password="" then there is indeed no password set. Eeks....

it is fixed in eXide 2.4.2