https://bugzilla.redhat.com/show_bug.cgi?id=1304882 --- Comment #17 from awilliam@xxxxxxxxxx <awilliam@xxxxxxxxxx> --- So I've put up a 4.3-9 with several changes: https://www.happyassassin.net/reviews/openqa/openqa.spec https://www.happyassassin.net/reviews/openqa/openqa-4.3-9.fc23.src.rpm I haven't actually *tested* it yet, so, have fun :) I'll do that tomorrow. I aimed to tighten up ownerships/permissions a bit and explain the ones that can't be changed, or look odd, along with all the changes noted in the spec: # The logfile mess is all gone, that's just working around AppArmor it seems # systemd_requires is expanded # build is 'parallel', but we also note that make does nothing at all ATM # the change to user creation scriptlets is done # the post-install message is moved to httpd subpackage post for now # openqa.ini and database.ini ownership/permissions are changed # unnecessary directory ownerships are dropped Note, if you want to test this stuff, using the ansible plays from infra will make it a lot easier: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/openqa the required variables are all documented in the comments, you can just set up a simple stub local playbook and define them plus the necessary hosts there and link in the roles directory from a checkout of the infra repo. We need to test both an upgrade of an existing install and a fresh one from scratch to make sure none of these changes busted anything... I still don't entirely grok that 'subdirectory ownership' thing, but I asked on #yum, and mls said: <mls> 06:09:12> adamw: I guess this is about subdirectories which include other files/directories also packaged in rpm <mls> 06:10:26> I think the security issue is that the non-root user can modify the directory while rpm messes (as root) with the directory contents 06:10:48> e.g. creates symlinks and the like. Ondrej (upstream) said he didn't add that comment and doesn't know why it's there, so that might be the best we'll get. It's not a script, I don't think, as Googling it returns no other locations of the same text. I don't really see a way around geekotest owning these directories, it needs to be able to create files in them. I did change it so that geekotest does not own /share and /factory, only the leaf directories. I believe that should be OK (it doesn't need write access to /share or /factory directly, I don't believe). I'll note that the Wordpress package has something very similar to what this now has: %dir %attr(0775,apache,ftp) %{wp_content}/plugins %dir %attr(0775,apache,ftp) %{wp_content}/themes %dir %attr(0775,apache,ftp) %{wp_content}/upgrade %dir %attr(0775,apache,ftp) %{wp_content}/uploads so either it's not really a problem or every Fedora wordpress instance in the world is vulnerable to it :) -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review