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:
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
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!