Hello my fellow Fedora friends! It's 01:00 in my local time and perhaps I should be resting instead of trying to figure out chicken-and-egg problems at such a time, but my tired mind is on the fence about the solution to one of my tickets and I would love the input of others: https://bugzilla.redhat.com/show_bug.cgi?id=1371984 Let's just say that daemon package A creates user/group A and depends on library B. One of library B's binaries needs to be installed setuid root because it is for PAM authentication, but I'd rather install the binary 4750 or 4700 than 4755. To do this, I can only think of four solutions: 0) library B installs with 4700, and daemon package A sets a facl on the binary to allow user A to execute it. This seems pretty cool, but also weird to me since it seems odd for a package to modify a file from another package. Additionally, it seems like future updates to library B might disrupt the facls that were set by daemon package A until the next time it was installed/updated. That sounds right anyway, and if it is right I think this option is a no-go. Simple tests with the install utility on my fs did obliterate facls when new files were installed over existing files. A crazy workaround for this problem might be to detect whether the facls are present before the upgrade with %pre, and restore them in %post. 1) library B creates group A (even though the library isn't necessarily only for daemon package A who is the only package to create this user/group at this time), and then sets its binary to 4750, owned by group A. This one is a little easier than the first option, since I'd only have to make an update to library B rather than both A and B. The only thing is that it seems kind of weird for library B to be creating a group called A, when library B is theoretically generally useful on its own and theoretically could have other packages that pull it in in the future. It would be weird for group A to exist if package A were not installed I think. Fortunately, it wouldn't need to create user A as well, only the group. 2) We could leave the problem up to documentation, instructing users to set the facls or group ownership. However, this will suffer from the same update problem that the first solution suffers from, and the user will need to reset the facls whenever this package were updated. 3) We could rely on an SELinux policy to ensure that only ejabberd can execute this binary. I don't like this for two reasons: users who disable SELinux wouldn't have the fallback regular Unix permissions as the second layer of defense. Secondly, unconfined users would still be able to run the binary. If there were ever security issues found in the binary itself, neither of these situations would be ideal. Option #1 seems to have the fewest technical concerns, so I lean in that direction. Hopefully sleeping will get my mind to its peak efficiency and I'll see some obvious solution in the morning, but I'd love to hear what others think. Is there precedent for this problem? Do you have any other options that I haven't thought of? Thanks for any input you can offer!
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
