Thank you, Simo.
First of all a disclaimer: I have very little knowledge of libnss_sss
communication with sssd so my judgement is based on a sort of fog.
On 11/27/2014 04:25 PM, Simo Sorce wrote:
On Thu, 27 Nov 2014 15:09:32 +0200
Nikolai Kondrashov <Nikolai.Kondrashov(a)redhat.com> wrote:
> While trying to arrange running sssd under cwrap in "make check" I
> came upon this roadblock:
> There doesn't seem to be a way to make libnsss_sss use server sockets
> in non-default location at runtime, only at build time. And it seems
> that doing it at runtime would be a security issue.
Why would it be a security issue ?
I was primarily thinking about environment variables, which I thought would
make it possible to change the libnss_sss responses completely with an
environment variable pointing to a different socket. And environment variables
are sometimes difficult to track and can come from various places.
> That means that we can't include tests involving libnss_sss
> "make check", as that is not guaranteed to be invoked on a build with
> a special location where the current user can write to.
We can use environment variables to find the socket as long as use
secure_getenv() (which means they will not work when running as a
setuid process, but otherwise will).
Wouldn't the non-setuid processes be also endangered by the possibility of
subverting their communication with sssd via environment variables?
If they would, what if we placed some restriction on the socket
ownership/permissions? Wouldn't it make it simpler? OTOH, I'm not sure how
that would work under cwrap.
The other option is to have a configuration file that libnsss_sss
reads, we haven't gone this route so far as we wanted to avoid adding
file operations to find out sockets, but it wouldn't be very hard to do
if we keep the file format so simple we do not need a file format
parser. But then this would again be a system level setting not per
process, so perhaps the env var route is better for testing anyway.
Um, this replaces the socket path specification problem with config file path
specification problem, essentially.
> This leaves us with being able to run these tests under CI only,
> which can arrange for special configure options and thus locations.
> Could there be another way? Am I missing something?
A last option would be to intercept unix socket calls in socket wrapper
too, and redirect them.
Hmm, this sounds interesting. But now I'm not sure if sockets is the only way
libnss_sss communicates with sssd (as per my disclaimer above).