Description of problem: Files in /var/softhsm/ and /var/opendnssec/ have incorrect permissions, group and owner. $ ll /var/softhsm/ total 8 -rw-r--r--. 1 root root 6144 May 15 14:48 slot0.db $ ll /var/opendnssec/ total 12 -rw-r--r--. 1 root root 0 May 15 14:48 kasp.db -rw-r--r--. 1 root root 0 May 15 14:48 kasp.db.our_lock drwxrwx---. 2 root ods 4096 Apr 18 23:16 signconf drwxrwxr-x. 2 root ods 4096 Apr 18 23:16 signed drwxrwx---. 2 root ods 4096 Apr 18 23:16 tmp Version-Release number of selected component (if applicable): opendnssec-1.4.5-2.fc20.x86_64 How reproducible: 100 % Steps to Reproduce: 1. $ yum install opendnssec Actual results: Files are owned by root instead of user "ods". This prevents "ods-ksmutil setup" from working (when run under user "ods"): *WARNING* This will erase all data in the database; are you sure? [y/N] y /var/opendnssec/kasp.db.our_lock could not be opened Error getting db lock Expected results: - All files are owned by user ods. - ods-ksmutil setup is run during first install - ods-ksmutil udpate all is run during upgrade This mitigates risk that somebody run "ods-ksmutil setup" from root (and screw file owner and permissions again).
This has been reported upstream by the looks of things, similar issue: https://issues.opendnssec.org/browse/SUPPORT-136
I'm actually going to turn this into a Security bug and file Fedora/EPEL6 trackers.
Created opendnssec tracking bugs for this issue: Affects: fedora-all [bug 1111335] Affects: epel-6 [bug 1111336]
(In reply to Vincent Danen from comment #1) > This has been reported upstream by the looks of things, similar issue: > > https://issues.opendnssec.org/browse/SUPPORT-136 I am not sure if this bugzilla is a security issue or not. Possible CVE request and reasoning here: http://www.openwall.com/lists/oss-security/2014/06/20/3 Regarding the SUPPORT-136 issue, CVE request is here: http://www.openwall.com/lists/oss-security/2014/06/20/4
https://issues.opendnssec.org/browse/SUPPORT-136 is https://bugzilla.redhat.com/show_bug.cgi?id=1111474
(In reply to Vincent Danen from comment #2) > I'm actually going to turn this into a Security bug and file Fedora/EPEL6 > trackers. Please note that original Fedora packaging prevents OpenDNSSEC from creating any key in the database. The slot0.db file if world-readable but write-able only by root. OpenDNSSEC is running under user "ods" by default so it can't effectively write any keys to the database so there is nothing to leak until somebody fixes file permissions. That is the reason why I considered this to be simple packaking bug instead of a security problem - it simply prevents OpenDNSSEC from working.
Well, the bug does make this a non-issue then. It's ideal to keep this open so that when is fixed the other is fixed as well, but Fedora (and presumably EPEL?) wouldn't be affected out of the box then, if this bug prevents anything interesting from being written in the first place.
I'm leaving the Fedora/EPEL trackers open so that they will get fixed there, but as far as a security flaw goes, I'm closing this bug since it is not a flaw.