On Wed, 2011-06-29 at 23:35 +0100, Matthew Ife wrote:
Hi Stephen,
I am working on the SSSD policy for local db management and hit across
an alert that I believed should be fixed in code.
The alert is because nscd.c called system() to request a flush command
to nscd if it exists.
This is a problem policy wise because this calls /bin/sh to execute the
command which in turn forces policy to allow a much greater access to
sssd to execute stuff that exists in /usr/bin and friends.
In the patch attached I replaced the system() request with a fork/execl
pair. This is much nicer in policy as I can change policy to call a
specific transition into the nscd_t domain directly without giving
access to sssd to the bin_t types in /usr/bin.
Please check the patch. I'm not familiar with talloc (I dont really
consider myself a C programmer of any merit) and my workaround to create
a char** array to talloc memory might be a bit daft to do. If you can
alter the code to something more elegant please feel free!
On Mon, 2011-06-27 at 07:13 -0400, Stephen Gallagher wrote:
> I happened to notice this email on the selinux list. This discussion
> would probably be best served cross-posted to
> sssd-devel(a)lists.fedorahosted.org, so we on the SSSD team can be
> involved if there are any code changes/improvements we need to make in
> order to further advance this proposal.
I took a look at the patch, and unfortunately it would need a fair
amount of rework to get it to function properly. However, it brings up
an interesting topic that I'd like to discuss with the SSSD list at
large.
The main reason for the nscd flush is because, for a time, we were
attempting to allow the SSSD to operate alongside NSCD. These days,
however, we've acknowledged that the two caches really don't interact
well and we strongly advise that users disable user and group support in
nscd while using SSSD.
So I'd like to propose that, rather than fixing this code to work in the
way Matthew is suggesting, we remove it entirely, acknowledging that
nscd/sssd interaction is unlikely to ever be safe.
Thoughts?