FS#57722 - [openfire] Use jabber user or same UID to resolve plugin issues and permission issues
Attached to Project:
Community Packages
Opened by AMM (amish) - Monday, 05 March 2018, 15:12 GMT
Last edited by Massimiliano Torromeo (mtorromeo) - Monday, 12 March 2018, 10:09 GMT
Opened by AMM (amish) - Monday, 05 March 2018, 15:12 GMT
Last edited by Massimiliano Torromeo (mtorromeo) - Monday, 12 March 2018, 10:09 GMT
|
Details
Description:
Openfire currently creates a new user called openfire and also use tmpfiles.d to change ownership of /etc/openfire and /var/log/openfire. (which is not correct way as they are not really temporary files) Also there are other issues. 1) One can not install plugins from openfire web interface because /usr/share/openfire/plugins/ is not owned by openfire user. So it can not store plugins there. 2) Also on starting openfire.server, java throws seemingly critical message: "java Critical Error! The home directory has not been configured" This is because /usr/share/openfire is set as home directory but it is not owned by openfire user. 3) Openfire tries to write logs to /usr/share/openfire/logs but fails, because it does not own the directory /usr/share/openfire and hence can not create logs directory Overall due to above issues - package seems incompletely configured and does not run "out of box" and administrator is required to set proper permissions before the openfire server can actually be run as expected. Additional info: * package version(s) 4.2.2 and earlier Steps to resolve: All above issues can be resolved by changing ownership of /usr/share/openfire to openfire user by using reserved id. Arch linux already has reserved user/group jabber (Reserved UID=GID=17) So instead of creating openfire user, package can use jabber user. Or if one still wants to name of the user as openfire then user.conf file can use reserved UID/GID (17) as follows. > cat user.conf u openfire 17 "openfire user" /usr/share/openfire then add following lines in PKGBUILD at the end of package() function: chown -h -R 17:17 "$pkgdir"/{etc,usr/share,var/log}/openfire ln -s /var/log/openfire "$pkgdir"/usr/share/openfire/logs With above 3 line change - there is no more need of tmpfile.conf and it can be done away with. And issues number 1, 2 and 3 above also gets resolved. And openfire runs out of box and admin can directly start web interface and do necessary setup via browser. Reference: https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database |
This task depends upon
Closed by Massimiliano Torromeo (mtorromeo)
Monday, 12 March 2018, 10:09 GMT
Reason for closing: Fixed
Additional comments about closing: openfire-4.2.2-6
Monday, 12 March 2018, 10:09 GMT
Reason for closing: Fixed
Additional comments about closing: openfire-4.2.2-6
As for the packaging itself, it is wrong to create an empty, root-owned directory (/var/log/openfire that is) in package() and then modify the ownership in tmpfiles.d -- instead the directory should *only* be created by tmpfiles.d
The use of /etc does make it look like the only option is a reserved UID which is sad because we want to limit the number of special snowflake packages that contain hardcoded UIDs.
First of all userid of 17 is already reserved for jabber aka XMPP. Openfire is nothing but jabber/XMPP server so the package should have used that reserved UID instead of creating new UID (or user?)
Plus I disagree that /var/log/openfire should be created by tmpfiles.d as it is NOT a temporary / volatile directory.
From man tmpfiles.d
tmpfiles.d - Configuration for creation, deletion and cleaning of *volatile and temporary files*
And logs are in noway intended to be volatile or temporary
My suggestion is much similar to /var/log/squid where directory owner is set to UID 15:15 in install file.
But with that method "pacman -Qkk" throws a complaint:
warning: squid: /var/log/squid (UID mismatch)
warning: squid: /var/log/squid (GID mismatch)
This warning can be avoided if PKGBUILD itself sets UID/GID instead of install script doing it. (thats what I have suggested in my bug report - chown -R)
About using /usr/share/openfire/logs. Thats what openfire seems to be using by default.
That is why I suggested use of symlink to /var/log/openfire (ln command suggested above)
The use of tmpfiles.d to create the log directory doesn't imply that it will destroy any log but, on the other hand, if you want to run arch with a /var mounted on tmpfs/ramfs then tmpfiles.d will ensure that the required directories will be restored at each boot without requiring a new install.
This kind of stateless system is described here if you are interested http://0pointer.net/blog/projects/stateless.html
I wanted to avoid switching UID now since it will create issues when upgrading but I don't have any alternatives if I have to avoid changing the ownership after installation.
I'll also fix the link to the log directory.
@eli I agree it's gross that it actually tries to write in /usr/share/openfire/logs but it's java, it's bound to be gross.
I could change the log directory by providing a log4j.xml but the admin panel is hardcoded to $HOME/logs so it's pointless...
I'll also try to address the issues with plugin installation (even though I would consider them user-data, which should be placed in /var, not in /usr)
Also plugins are user-data but admin interface tries to put them in /usr/share/openfire/plugins and fails doing so.
My only aim is that openfire should atleast run out of box with default settings without throwing errors.
Appreciate your time and efforts. Thank you.
I wasn't expecting much from a java application, true.
If openfire insists on using the installation directory as $HOME but only writes to a log directory, would it be possible to skip modifying permissions altogether in that case? What happens if it doesn't have ownership of $HOME?
@amish,
More generally tmpfiles.d is a good way to create directories that depend on the target system, e.g. dynamic uids
As for squid, that appears to be an incomplete migration to sysusers.d/tmpfiles.d and should have originally happened in package() anyway, so that is wrong too.
"java Critical Error! The home directory has not been configured"
Also since plugin directory is also under $HOME. If you put any plugin there it throws lots of Java exceptions because it tries to UNZIP/UNTAR the plugins into plugin directory.
I believe squid reference here was picked up and new release today removed install file altogether.
Also note to @mtorromeo - why give 755 to /var/log/openfire. 750 is more secure.
Permissions in PKGBUILD and in tmpfiles.d are not consistent.
in PKGBUILD permission given are 755 but in tmpfiles.d its 755 and 750 for different directories.
oh well, java, what can you do. I guess it will simply have to write to /usr/share
So we are sticking with the dedicated openfire user but I really wanted to avoid reserving a UID for it.
In defense of my use of tmpfiles.d I will argue that the one-line description from the man page is definetely over-restrictive as in the same man page you will find the description of all the supported flags and features like, for example, the "Z" flag that is dedicated to "Adjust the access mode, group and user...", "a" for posix acls, "t" is for extended attributes, "q" for subvolume quota groups, "L" for symlinks and so on.
It may still be that my use of it was an abuse of its functionalities but it is clearly designed to do more than "creation, deletion and cleaning of volatile and temporary files".
https://www.archlinux.org/todo/switch-to-systemd-sysusers/ involved a lot of transitioning from statically reserved UIDs for folders in package(), to tmpfiles.d and I don't regret any of it.
It just doesn't work out great when you need to package files with specific contents, owned by an unpredictable UID...
Only the number 17 is reserved for jabber/XMPP daemons/servers. We can add openfire as package using that UID in Wiki.
So you can keep the name openfire as is, just assign UID as 17. (just like its done for squid and httpd).
> cat /usr/lib/sysusers.d/squid.conf
u proxy 15 - /var/empty
> cat /usr/lib/sysusers.d/arch.conf
...
u http 33 - /srv/http
# my suggestion
> cat /usr/lib/sysusers.d/openfire.conf
u openfire 17 "openfire user" /usr/share/openfire
This way you can change the UID in PKGBUILD itself using "chown -R 17:17 ..." and pacman -Qkk will not throw warnings either.
Also why give 755 to /var/log/openfire? It can create information leak. (if log file also has o+r).
So in my opinion its better to assign 750.
I have following suggestions:
1) In PKGBUILD package() function
#directory creation / permissions
install -dm755 etc usr/{lib,share}
install -dm750 etc/openfire usr/share/openfire{,/resources}
#at the end of package() function - to avoid pacman -Qkk warnings
chown -h -R 17:17 "$pkgdir"/{etc,usr/share}/openfire
2) More secure - tmpfile.conf (use capital Z)
d /var/log/openfire 0750 openfire openfire -
Z /etc/openfire 0750 openfire openfire -
Z /usr/share/openfire 0750 openfire openfire -
3) user.conf
u openfire 17 "openfire user" /usr/share/openfire
PS: if you use chown command above then Z lines are not required at all
Note: currently I am not able to test capital Z thing in point 2) above. Will test soon. But just suggesting that this could be done.
It sounds like it would be sufficient to merely restrict that in /var/log/openfire, right?
As for switching to Z, is there a reason all files recursively must be changed? What else needs write permissions there, other than the $HOME itself and perhaps the plugins directory?
Also /etc/openfire, does it need write permission there? Or is e.g. username/password pairs stored there?
No, the reserved uid 17 cannot be used like this because it is also used by other packages (for example ejabberd) and you will end up with 2 definitions of the uid 17 with different usernames and different home directories.
That is exactly what uid reservation is supposed to prevent.
It's fine to restrict /var/log/openfire to 750, I'll change that but there is no need to change recursively everything under /etc/openfire and /usr/share/openfire so lowercase z is sufficient.
I also don't see the point of applying 750 to /usr/share/openfire. There is no private data there.
@eli
If I remember correctly openfire needs write permission in /etc/openfire at least for the security keystore (the primary reason for restricting mode to 750) but there may also be other files it wants to write to.
About private data, if directory is owned by root then its ok to keep it 755. But if directory is owned by a particular user then its more secure to switch to 750 especially when you know that data/executables inside it, is supposed to be accessed only by that particular user.
Also you never know when openfire guys will decide to have some kind of private data in there, in future. Thats when such relaxed permissions get overlooked and then your system starts leaking data till you realize it and by then it may be too late.
Or if you still want root to own most of files then you can change group to openfire and then change permissions to 750/640. (etc and plugins directory will still need write access to directory and files)
So may be all files owned by root with group as openfire.
Most directories and file 750/640
/usr/share/openfire/plugins and /etc/openfire and /var/log/openfire owned by openfire
Nonetheless thank you for your quick updates :)
So the jabber user is definitely out of the question IMO.
I thought about a solution for avoiding writing in /usr and ending up with userdata there.
I would switch the openfire home directory to "/var/lib/openfire" similarly to what a lot of other services like redis/mysql/openldap do.
The directory /var/lib/openfire and /var/lib/openfire/plugins would be created by tmpfiles.d with the appropriate permissions.
Then I would link there, using tmpfiles.d's "L" flag, the conf, logs and resources directories and the only packaged plugin in /var/lib/plugins/admin.
/usr/share/openfire would remain root owned with no special handling.
The only permission changes after package installation that would remain is /etc/openfire but this way I would manage to avoid uid reservation.
Also /usr would most probably be read-only so you wouldn't be able to install any plugin anyway.
In a stateless system a reboot should be equivalent to a factory reset.
I use postgres database instead embedded db so I can test its functioning with new layout as well.
What's important is the "-DopenfireHome=/var/lib/openfire" flag that I changed in the service file [1].
I tested the upgrade from one version of the package to the other. The user, as you said, kept the previous home in /usr/share/openfire but it worked just the same.
https://git.archlinux.org/svntogit/community.git/tree/trunk/openfire.service?h=packages/openfire
Two things that I noticed.
One is "pacman -Qkk openfire" gave lots of warnings just as I was expecting. But I doubt it can be resolved without fixed UID number. So may be we can ignore the warnings? (or is there any other way?)
> pacman -Qkk openfire
warning: openfire: /etc/openfire (UID mismatch)
warning: openfire: /etc/openfire (GID mismatch)
warning: openfire: /etc/openfire/crowd.properties (UID mismatch)
warning: openfire: /etc/openfire/crowd.properties (GID mismatch)
warning: openfire: /etc/openfire/openfire.xml (UID mismatch)
warning: openfire: /etc/openfire/openfire.xml (GID mismatch)
warning: openfire: /etc/openfire/security.xml (UID mismatch)
warning: openfire: /etc/openfire/security.xml (GID mismatch)
warning: openfire: /etc/openfire/security (UID mismatch)
warning: openfire: /etc/openfire/security (GID mismatch)
warning: openfire: /etc/openfire/security/client.truststore (UID mismatch)
warning: openfire: /etc/openfire/security/client.truststore (GID mismatch)
warning: openfire: /etc/openfire/security/keystore (UID mismatch)
warning: openfire: /etc/openfire/security/keystore (GID mismatch)
warning: openfire: /etc/openfire/security/truststore (UID mismatch)
warning: openfire: /etc/openfire/security/truststore (GID mismatch)
Second is current PKGBUILD does not ship with any plugins (except admin plugin).
Openfire source ships with many excellent plugins. So I have slightly modified PKGBUILD to also build and package some plugins that I want (jar files).
But those plugins go into /usr/share/openfire/plugins and since openfire now looks for plugins in /var/lib/openfire/plugins .. those plugins are no more used.
So in case in future, default package also decides to ship some plugins, it is going to be an issue (while installation as well as while upgrading).
As they can not be put in /var and we can not keep on creating symlink in tmpfiles.d for each JAR file.
So what I have done is added a line in service file
ExecStartPre=-/bin/sh -c '/usr/bin/install -g openfire -o openfire -m 640 -p -t /var/lib/openfire/plugins /usr/share/openfire/plugins/*.jar 2> /dev/null'
This copies any plugins in /usr to /var just before running openfire and openfire uses them. This also takes care of future upgrades to plugins. And also can be used for stateless systems.
Ofcourse I know that point 2 is my personal problem but it can surface in future for default package too, if it decides to ship some plugins too.
Rest all is perfect and may be we can close the ticket.
Thank you :)
etc/openfire/security.xml also needs to be in backup() in PKGBUILD.
It stores encryption type (AES or blowfish) and secret/key etc.
If its not put in backup then on upgrade those settings vanish (or switch to defaults)
PS:
You may as well put etc/openfire/crowd.properties in backup() too.
I dont use/modify it but from its contents looks like thats also one of configuration files which should NOT be overwritten on upgrade
Including links for every plugin in tmpfiles.d would not be too complicated but the reason why they are not included in the package is that then you would have them enabled by default and when updating/removing them from the administration panel you would overwrite/delete files that are provided by the package.
Also, every change to the plugins would be overwritten by every update of the package.
The fact that the package weights ~20M instead of ~100M also helps.
All the plugins are also available from the web interface anyway.
I'm going to close this now. Thanks for reporting this issues.