https://bugzilla.redhat.com/show_bug.cgi?id=1304882 --- Comment #37 from awilliam@xxxxxxxxxx <awilliam@xxxxxxxxxx> --- There's an irony here: if we change initdb to accommodate database.ini *not* being owned by geekotest, we might actually *create* an attack vector in the case where it *is* owned by geekotest. The problem with database.ini being owned by geekotest is that, in theory, an attacker who could get the webUI to execute arbitrary code could mess with it, right? So, what could an attacker do with that? Well, try to have openQA mess with *other* databases, I guess. Here's one attack: they could fiddle database.ini to point to some other database, and then when initdb ran, it might mess with it. As things stand, this wouldn't work. The attacker can't call initdb with elevated privileges themselves, but they can booby-trap database.ini and wait for the package scripts to run it as root. However, the script currently drops privileges before it tries to connect to the database, so this attack isn't going to work. Our attacker is foiled! If we change initdb so it connects to the configured database as root *then* drops privileges, we might actually *enable* this attack. I don't know for sure - it might be the case that subsequent operations on the database after privileges are dropped would fail even if the schema instance was created before privileges were dropped, I'm not sure how that works. But it at least seems *more* possible. oh security, how I hate you... -- 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