On Wed, 2018-01-31 at 14:55 +0100, Fabiano FidĂȘncio wrote:
Sumit,
On Fri, Jan 26, 2018 at 9:01 PM, Sumit Bose <sbose(a)redhat.com> wrote:
[..]
I'll leave the other 2 questions to Simo. :-)
I wonder if there is a chance that e.g. a signal can force to backend to do
> something else when running with the changed euid?
If I am not wrong we pipe all signals back quickly into tevent events,
so signals should not cause issues. This should be carefully checked
but I would be surprised if any of our signal handlers do any I/O
besides triggering a tevent via pipe, it is not recommended to do that
anyway.
On whether seteuid influences the delivery of signals I am not 100%
sure, but I think only a real uid change will affect that, not the
effective uid. (on the receiving side which is what we care about).
So I think we are OK here.
That said, are we sure we retain CAP_SETUID ?
> Is there something you do not like about the approach of PR498?
Here my comments from the tracker:
FWIW,
I see nothing wrong in keeping CAP_DAC_OVERRIDE, the process is running
as root and can impersonate users at any time so removing this
capability does not change the security stance.
However it may make some errors less severe if people use seteuid() to
change the effective id of the user, because then the process cannot
alter data or access compartmentalized data by mistake.
Opening permissions on the files negates the benefit of using seteuid()
so it is the least desirable way to handle this "issue".
HTH,
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc