On Thu, Feb 1, 2018 at 11:25 AM, Sumit Bose <sb...@redhat.com> wrote:
> On Wed, Jan 31, 2018 at 10:01:15AM -0500, Simo Sorce wrote: > > 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 <sb...@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". > > Thank you for the explanations, so I'm fine with using seteuid()/setegid(). > I've updated the design page and send the patches to FleetCommander developers so they can test it. I'll update the github PR as soon as I have their feedback. So, summing up, thanks for the inputs! > > Fabiano, nevertheless I'd like to ask some questions about the profile > files, please let me know if I should better ask the Fleetcommander > developers. > > Is it expected that the user can change the data in the file? Or is it > the other way round that it would be better that the user only has > read-only access so that the admin can force some settings? > I'd say not. So, maybe going for a read-only solution would be better. Here, I'll confirm this with Oliver. > Is it possible that there is any sensitive information in the profile > files or would it be ok if anyone can read it? (hm, while writing the > question I started wondering if I would be happy if everyone knows that > my desktop background is pink_unicorns.jpg?). > This is a quite good question and I'll redirect it to Oliver and get back to you as soon as I have both answers. > > bye, > Sumit > > > > HTH, > > Simo. > > > > -- > > Simo Sorce > > Sr. Principal Software Engineer > > Red Hat, Inc > > _______________________________________________ > > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org > _______________________________________________ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org >
_______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
