Arch Linux

That is pretty gross, why does this need to use /usr/share/openfire at all and can it use a different log directory instead?

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.

I am not sure above reply was reply to my bug report or the original package's packaging.

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)

If you consider logs to be volatile or not is your own discretion but there are valid use cases where it may be considered volatile.
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)

Not sure why anyone would want to run openfire on a stateless system but I agree about tmpfiles.d for that case.

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.

@mtorromeo,

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.

If it doesnt have ownership of $HOME then it gives this error:
"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.

Yes, I fixed squid. ;)

oh well, java, what can you do. I guess it will simply have to write to /usr/share

Actually I can't use the reserved jabber UID even if I wanted to since, as we already determined, openfire requires its home directory to be /usr/share/openfire while the jabber user would be already defined with no home directory.

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".

If so, then Arch Linux as a distribution heavily abuses tmpfiles.d to avoid statically reserved UIDs where possible. :p
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...

jabber user is not created currently by default.(no package uses it - as per that UID/GID page)

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.

Just noticed new openfire package was released with some changes to PKGBUILD

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.

Which files in /usr/share/openfire actually contain data that needs to be kept secret? By default I think we should try to avoid situations where e.g. pacman -Qkk returns warnings because the files cannot be read without root.

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?

@amish
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.

I doubt user will have both ejabberd and openfire running together. Would probably a rare case. If they still want to have both, either they can change home directory manually or change UID number. But in most cases, user will either pick ejabberd or openfire and not both. (its like it will either be postfix or qmail or sendmail)

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 :)

The difference for postfix, qmail, sendmail etc is that they could all use the same "mail" user exactly as it is, with the home configured in /var/spool/mail and the same exact username, and in fact postfix defines its own user "postfix" with a different id and home directory.

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.

Forgot to mention that the issue is not only present when you install both openfire and ejabberd together but also when you migrate from one to another which is more likely.

If you put plugins to /var then it wont work in stateless system as plugins installed by user would simply vanish on every reboot. May be that would not be expected to happen.

That's the point of a stateless system.
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.

Ok. Fine. I can give a try to your new layout and test it if all works fine.

I use postgres database instead embedded db so I can test its functioning with new layout as well.

Just published openfire-4.2.2-4, it worked well in all my tests.

Actually I forgot to publish a last-minute change that I did in my tests so I had to release openfire-4.2.2-5. Sorry about that!

That looks like a pretty nifty fix, but please note that changes to sysusers.d for people upgrading who (therefore) already have those users, will need to also be fixed in a post_upgrade scriptlet running usermod.

Yeah, I know, but it turns out that the user's home directory doesn't really matter.
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

Huh, so yeah that doesn't really matter then and therefore probably isn't worth adding an install script.

Ok I tested everything that I could and most of things work perfect. (and out of box)

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 :)

Found minor bug:
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

I added the missing files in backup=()

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.