Description of problem: After I setup jabberd to use sqlite and created an empty file /var/lib/jabberd/db/sqlite.db which was world readable (mode 644). Since it will contains passwords, this should not happen. Also /var/lib/jabberd/db/ is mode 755 and all other dirs in /var/lib/jabberd Version-Release number of selected component (if applicable): jabberd-2.2.8-2.el5 - creation of sqlite.db jabberd-2.2.11-1.el5 - directory permissions, did not test creation of sqlite.db How reproducible: always Steps to Reproduce: 1. install jabberd 2. setup to use sqlite 3. start it Actual results: contents of /var/lib/jabberd are world readable Expected results: Only the jabberd user and maybe the group should be able to access /var/lib/jabberd. Maybe it is enough to restrict only /var/lib/jabberd/db, if the log files are created with proper permissions. Additional info:
In response to bug 647095, comment 1: I am not sure, whether a direct update to stable is really required here. I guess most likely a jabber server will not be hosted on a system where untrusted users have shell access. Also the server admin might have set the permissions of the sqlite file correctly. And in case someone was hit by this bug, waiting some days will probably not make it worse. Afaik at least the current Fedora update policies require even some delay for security updates, therefore this might apply to epel, too. Btw. Fedora might be expose this bug, too.
I fixed anything which was possible for me concerning this issue. I have a new package lying around locally for which rpmls now shows the following permissions: drwx------ /var/lib/jabberd drwx------ /var/lib/jabberd/db drwx------ /var/lib/jabberd/log drwx------ /var/lib/jabberd/pid Unfortunately I can't influence the rights of the sqlite.db file at generation time, so it may have other permissions than the paths above. Anyway, the above permissions should prevent anyone from world or group to even get to the path to the sqlite.db and actually is the behavior you expected, right? :) I'd be glad if you like to test the package before I'm going to push another update. Please let me know if you like to do so. :)
(In reply to comment #1) > In response to bug 647095, comment 1: > > I am not sure, whether a direct update to stable is really required here. I > guess most likely a jabber server will not be hosted on a system where > untrusted users have shell access. Also the server admin might have set the > permissions of the sqlite file correctly. And in case someone was hit by this > bug, waiting some days will probably not make it worse. Okay, I'll go the way through testing then, this hopefully gives users another chance to check out the package before it gets pushed to stable. :) >Afaik at least the > current Fedora update policies require even some delay for security updates, > therefore this might apply to epel, too. Btw. Fedora might be expose this bug, > too. It's likely the Fedora packages are also affected by the issues you reported, I actually built the updates for F13, F14 and EL5 almost at the same time. When any issue is fixed, I will provide an update for all affected releases. :)
(In reply to comment #2) > I fixed anything which was possible for me concerning this issue. I have a new > package lying around locally for which rpmls now shows the following > permissions: > > drwx------ /var/lib/jabberd > drwx------ /var/lib/jabberd/db > drwx------ /var/lib/jabberd/log > drwx------ /var/lib/jabberd/pid > > Unfortunately I can't influence the rights of the sqlite.db file at generation > time, so it may have other permissions than the paths above. Anyway, the above > permissions should prevent anyone from world or group to even get to the path > to the sqlite.db and actually is the behavior you expected, right? :) The permissions of the sqlite.db when it is created can be set with umask(2) I guess. This is worth forwarding to upstream, unless it is fixed in the recend update. Btw. it is probably ok to keep the dirs group readable. > I'd be glad if you like to test the package before I'm going to push another > update. Please let me know if you like to do so. :) I can at least try to proofread your changes.
Okay, then here we go: SRPM: http://dmaphy.fedorapeople.org/jabberd2/jabberd-2.2.11-2.fc14.src.rpm Spec: http://dmaphy.fedorapeople.org/jabberd2/jabberd.spec This one should fix #647095 and #647100 (this issue). Seems to work fine here on my F14 Machine. The EPEL build for my CentOS 5 machine is still running, but as soon as this is done I'll check that out there too.
Reported this issue to upstream: https://bugs.launchpad.net/centos/+source/jabberd2/+bug/668790
jabberd-2.2.11-3.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/jabberd-2.2.11-3.fc13
jabberd-2.2.11-3.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/jabberd-2.2.11-3.fc14
jabberd-2.2.11-2.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/jabberd-2.2.11-2.el5
There was no feedback from your site until today, thus I pushed the updates now as they are a bit important. Thanks very much again for reporting the issues. Feel free to give Karma on the updates depending on your test results if your going to review them. :)
jabberd-2.2.11-2.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update jabberd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/jabberd-2.2.11-2.el5
jabberd-2.2.11-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
jabberd-2.2.11-3.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
An additional note just for completeness: The author of jabberd2 closed the issue I reported to upstream today with the hint to set the correct umask. https://bugs.launchpad.net/jabberd2/+bug/668790
(In reply to comment #14) > An additional note just for completeness: The author of jabberd2 closed the > issue I reported to upstream today with the hint to set the correct umask. > > https://bugs.launchpad.net/jabberd2/+bug/668790 I cannot access this bug. Setting the umask is the correct fix, but afaics it needs to be done by jabberd2, since making the db world readable is always wrong except for strange setups afaics.
jabberd-2.2.11-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.